Alliance Data -
I was brought on as the first Ux Accessibility Designer to analyze their client-facing site that allows a user to apply for a credit card and manage their credit card accounts.
Abiding by WCAG 2.1 Level AA guidelines, I addressed problems from an ADA, heuristic, and usability perspective. A complete redesign was out-of-scope, so I only made design changes to meet accessibility needs and coding suggestions to the development team.
- 1 – Accessibility Analyst
- 2 – Accessibility Ux Designer
- 6 – Front-end AngularJS Developers
- 2 – Content Managers
- 2 – Ux Copywriter
- 10 – Back-end Developers
- 3 – Compliance and UDAAP Agents
- 3 – Systems Analyst
- 4 – Quality Assurance Testers
- 2 – Scrum Master
- 2 – Product Owner
- 1 – Project Manager
- Marketing Department
- 3 – Lawyers
- Create Personas
- Accessibility Analysis
- Interaction and Visual Redesign
- Training other departments on how WCAG 2.1 Level AA guidelines affect their roles
- New feature design reviews
- Creating Accessibility Design Specifications
- Review Spec with the Ux Team, Stakeholders, Copywriters, Compliance, Legal, Systems Analysts, Development Team, and Quality Assurance Testers
- Training Quality Assurance Testers on how to use assistive technology
I did not have access to any of their users and couldn’t conduct contextual research with individuals who had disabilities.
I did have access to user demographics, and I pulled knowledge from my previous interactions with individuals with disabilities to create personas.
The creation of personas was an essential step despite my lack of access to real users because I needed to remove as much bias as possible when analyzing and redesigning components of the Account Center.
These personas also helped other individuals on the team keep the struggles and potential needs of disabled users in mind.
I created three personas that would capture a wide range of cognitive, learning, and physical disabilities. My personas included sections that covered:
- Background on how they became disabled and how long they’ve been that way
- Aptitude towards learning new things
- Assistive Technology they use
- Attitude toward overcoming challenges
- Main challenges they face while navigating a website
- The environment that they would access Account Center
- The tools, applications, software, and electronics they use everyday
- A quick preview of the process the user takes when interacting with Account Center and their goals
To protect Alliance Data, I will not call out anything specific. I will talk about my process and unique documentation for this particular company.
I received an initial accessibility assessment from an analyst that called out the bare minimum the company needed to do to “not get sued.” I then took their findings, did my analysis from a heuristic perspective.
My goal was not only to make the interface accessible but a good experience for all types of users. I initially called out the issues cardholders with disabilities would have, but then I had to look at it from an inclusive design point-of-view as to not create a worse experience for those who aren’t disabled.
I created a powerpoint template that would compare components one by one between the current design of the interface to the new design changes I suggested and reviewed with the Ux Team before presenting them to the project’s stakeholders: product owner, business analyst, and Ux director.
Once the design changes were approved. I placed them into my accessibility spec with the rest of my callouts. Ux copywriters, compliance, UDAAP, systems analysts, developers, content management, and quality assurance testers absorb my accessibility spec. I analyzed the Account Center feature by feature. Within a year I have assessed the universal components found on the secure side of the account center, legal documents, their message center, payments portal, account dashboard, help FAQs, transactions, and statements.
For most of the features I created the new designs in Photoshop and pulled screenshots over into Axure for annotations.
My annotations were broken into these seven categories so that the other team members could absorb them on the project. All but two of us had experience executing our roles with meeting WCAG guidelines in mind, so the issues and fixes were written in layman’s terms to help all parties involved come up with the best solutions for copy, legal, CMS, development, and testing.
- Violated and Supportive WCAG Guidelines
- Accessibility Issue in layman’s terms
- Accessibility Fix in layman’s terms
- Accessibility Coding Requirements
- Accessibility Copy included both visible and screen reader only copy
- Content Management notes to help with building schemas
- Redesign notifications if something was removed, moved, and added