Advocating and annotating for accessibility (a11y)
In this project, I used my expertise as a Sr. Accessibility designer to collaborate ensure an accessible experience during an account preferences page redesign at a major U.S. pharmacy. I advocate for the needs to users with disabilities throughout the design and development process. This work is ongoing.
​
Some information is removed or modified due to confidentiality.
Project overview
A leading U.S. pharmacy needed to update its account preferences page. The current experience is outdated and lacks key accessibility features. This flow needs to be updated for web, iOS, and Android platforms.
The team
Goals
-
Advise and collaborate with the UX/UI designer to create an updated design that is accessible to all and follows the pharmacy's new design system
-
Develop a more accessible and intuitive experience for all users
My role
Collaborating with UX/UI
I had daily meetings with the project UX/UI designer to provide a11y input on their redesign work. I provide input on the entire experience, from which elements from the UI kit are selected to content alignment. Throughout my work, I prioritize the needs and experiences of users with disabilities. Following is an example of how my input has led to more accessible design choices.
​
Some information is redacted for confidentiality.
In the old experience, each piece of login information could only be edited by selecting a button with pencil icon and red text reading "Edit" on the right-hand side of the screen. This presented a few issues:
-
All buttons only read "Edit", so screen reader users would not know which field they would be editing if selected
-
Locating the "Edit" button all the way to the right, far away from the field, would be difficult to appropriately select for screen magnification users and users with limited mobility or tremors. These users may not even know the buttons were there, and if they did, they'd have to "trace" left to right. This requires a high level of accuracy.
-
Because the text was red and the button was not surrounded by a border, it looked like a "Cancel" button on first glance. This could be confusing for users that rely on patterns to understand the web, such as older users or users with cognitive disabilities.
The new experience makes several improvements for both accessibility and UX:
-
All buttons contain the name of the field the user would be editing (e.g., "Edit email address" rather than "edit"). Unique button text is a major improvement for screen reader users.
-
The "Edit" buttons are now located directly below the corresponding field. This enhances scannability, makes the buttons more discoverable, and also makes the buttons much easier to select for users with screen magnifiers and users with limited mobility and tremors. They can now scroll down, instead of "tracing" left to right.
-
Buttons are now dark gray and surrounded by a border, marking them visually appear more like buttons by following established patterns.
Annotating the experience
This experience required three separate accessibility annotations: one for web, one for iOS, and one for Android. Each platform has unique considerations and accessibility features that must be incorporated when developing the experience.
Using the pharmacy's established Figma a11y annotations kit, I annotated each version of the design to communicate these features with developers. Following are samples of those annotations.​
​
Some information is redacted for confidentiality.
Web annotations
The web experience allows users to edit multiple fields on the same screen. Examples of a11y features called out include but are not limited to:
-
Headings add heading levels
-
<Labels> for field inputs, and what should be read out by a screen reader when an associated checkbox is checked or unchecked
-
Button types (e.g., "button", "submit") accessible names, and and changes in focus management when buttons are selected
iOS annotations
iOS annotations needed to be handled differently because of Apple's native accessibility considerations and features. Examples of a11y annotations and experience modifications include, but are not limited to:
-
Simplified screens with fewer fields
-
Using informative groups, rather than headings, to group information
-
Identifying custom interactive controls, including their labels, values, traits, and any important hints not built in by Apple
Android annotations
Because Android is a fractured ecosystem, there are additional a11y considerations when annotating. I was not able to be as prescriptive and detailed, so I instead communicated how elements should function. A11y annotations included, but were not limited to:
-
Simplified screens with fewer fields
-
Accessible names for buttons
-
Larger touch targets for touch to explore users
-
Dynamic button behaviors
Handoff to development
When a11y annotations and design annotations were completed, the UX/UI designer and I conducted a full walkthrough of the experience and annotations. This ensured that the developers understood the annotations and why we were recommending specific approaches. It also allowed developers to suggest alternatives they felt were more appropriate.
​
This collaboration is continuing as developers create the experience.