How to design for accessibility in digital products?
Accessibility in digital space is becoming a standard practice and a lot of companies have started adopting it. It is still a niche topic and important for designers to learn more about it. Unfortunately, it is not covered properly in the design school curriculum or as onboarding training in organizations around the world.
A few years back, I was introduced to accessibility while working for an app (as a mandatory step before shipping). I had limited knowledge of the topic and had to deliver the end-to-end accessibility experience for the product.
When I started my research in the area, it was eye-opening to see the large number of users struggling with the product because of a lack of sensitivity for accessible product experience. Owing to the strict timeline, I reached out to many designers and relevant people to understand more about the guidelines and patterns to get started with the work. This experience helped me to understand the fundamentals of accessibility.
During the process, I realized 2 things:
- Accessibility should be an integral part of the design process rather than just a checklist item.
- There are no set rules of accessibility. You need to think through the whole flow from the user’s point of view and make every feature accessible from the very start.
I have been working and learning about accessibility for about 2+ years now. Seeing the lack of awareness and guidance in the space, I wanted to share my knowledge and learnings with the design community.
Who are we designing for?
It is important to understand the challenges which users are currently facing while accessing any digital experience on mobile or web screen.
1. Permanent disability:
- Physical disability: This category consists of users who have a permanent physical disability. For example, people who don’t have hands or fingers, face a lot of challenges to use mouse/touchpad/trackpad, touch screen, and so on.
- Visual disability: Users who are visually impaired, with partial visual ability, or color-blindness face challenges to interpret and interact with the UI because of no visual feedback.
- Motor control: Users who have a motor deficiency can’t hold anything precisely. It is a major challenge for them to use a mouse or trackpad.
- Speech and hearing disability: People who can’t speak, hear, or with partial ability face difficulties with the VUI(voice user interface).
2. Temporary disability: Users who have temporary disabilities because of accidents or disease. For example, fractured hand/fingers or eye infection or ear infection, etc. These disabilities happen for a period where users face the challenge to perform any task with the interfaces.
3. Situational disability: This is the disability that happens in specific situations. For example, using infotainment features (navigation/audio setting) while driving, using mobile screens in sunlight, etc.
How to design for accessibility?
In addition to the design process, we practice the accessibility process in our design system. It’s more efficient if the accessibility criterion is incorporated early in the design process.
Decoding the standard practices of accessibility:
It is a vast subject and it’s challenging to solve for all the use cases. There are 6 major elements to define while you design for accessibility. There are more to explore but these are fundamental steps on a high level.
- Keyboard navigation
- Keyboard shortcuts
- Screen reader
- Headings(works with screen reader only)
- Landmarks(works with screen reader only)
- High contrast
1.Keyboard Navigation / keyboarding:
Keyboard navigation enables users who have physical disability and motor control issues. The user should be able to do anything with a keyboard that you can do with a mouse or trackpad.
The user should be able to navigate the app with the help of keyboard navigation. This act as a primary tool to navigate in the UI. ‘Tab” is used as the primary key to move the focus from one interactive element to another on the page. As a designer, we need to define the tab order/sequence for any page which should make sense in terms of page layout and content.
For mobiles ‘swipes’ define the sequence of the focus element.
Keyboard Navigation for Web
Above is the tab sequence for the app home page. Generally, the sequence is from left to right then top to bottom but try to keep the focus into the primary element as early as possible. Above Tab-1 is about the group of primary navigation so it starts from there. The tab order works in the loop so after the Tab-8 again it will start from Tab-1.
keyboard navigation can be defined by Tab stops and with the help of arrow keys within a single tab stop. For example, the Search experience is about one Tab stop but for search suggestions and other interactive elements can be defined by arrow keys.
2.Keyboard Shortcuts:
If everything is a tab stop, then it would take forever to navigate a screen, especially with a large list of content. Shortcuts can be invaluable if they are applied consistently.
Frequent or quick actions and keys like Home and End are examples, as is. Ctrl + Z. However, they are not a replacement for efficient keyboard navigation.
Below is a snapshot, where I had defined a list of shortcut keys for an app, we should use the same shortcuts which are being used everywhere. Like in Windows apps or other Microsoft web apps, ‘/’ or ‘Ctrl+E’ opens the search box. We should only define shortcuts for frequent actions and a few important actions. There should be a way to trigger this list in the help section and with a shortcut(Ctrl + .)as well.
3.Screen reader/Narrator:
See-through the eyes of visually impaired
This is how visually impaired users “see” the UI. We ensure that to have the right descriptive labels and instruction. The screen reader reads out the content and helps the users to navigate. It is the voice-based navigation which absolutely a necessity for the visually impaired or partially impaired people.
It works with the keyboard navigation and reads out the descriptions on each tab stop. Users will have to turn on the setting for the narrator/ screen reader in the OS settings to use this.
Design specifications of the screen reader: Say the most important things about control first. Most visually challenged users don’t even wait for the entire reader string, and move ahead.
The below example is about screen reader spec for the different tab stops which we defined early in the keyboarding. So if your tab-stop moves from 1 to 2 it will read out the description for both elements respectively. It is about defining the labels for Name, Role/type, and Value/state.
So for ‘1’ it will say- “Navigation menu, use up and down arrow key to navigate between 5 menu items.” All files..menu item..selected..1of 5.
‘2’ it will read out: Recent..menu item..not selected..2of 5.
What are these formats for giving labels?
- Dialogue: It sets the context of the control you have landed. For example, “Opening the panel. See all your download history here.”
- Name: Usually it is the visible label of the specific control, such as “Save” or “Download history”. Sometime in the absence of any label a descriptive text or synonyms can be added as a label.
- Role/type: It defines the type of interactions for example. “Dropdown”, “Radio choices”, “Link”, “Button” etc.
- Value/state: This describes the interactive state of the control. Ex: “Disabled”, “Selected” etc.
- Hint: Whenever there is a complex interaction it is good to keep a hint text so that the user can understand it and perform the task.
4.Color contrast :
To make our products inclusive to all vision conditions, there need to be minimum contrast levels for content. High contrast themes increase contrast even more for users with low vision.
This is important where specially-abled user
a) Who are partially blind
b) Who has Colorblindness
c) Who has low vision
Minimum contrast ratio:
- Interactive controls, texts, labels, and icons should have a minimum contrast ratio of 4.5:1 to have good readability.
- Non-text interactive elements against the background and the different adjacent states with each other should have a 3:1 contrast ratio.
- The color theme is defined for the texts, interactions, and backgrounds which maintains the contrast ratio.
High contrast mode:
High contrast themes inside the windows settings. Therefore the Apps for windows platforms should support this. High contrast is defined for users who are color blind or for those who have the partial visual ability.
Maintain the minimum color contrast ratio for dark themes as well.
5.Landmarks:
As the name suggests it is used to define the identifiable regions in a page like navigation, search, form, etc. This is useful for visually challenged users, where they use it to quickly understand the page layout and content structure by scanning the regions. Defining landmarks is about defining the different regions on the page.
Users can press “D” in the scan mode/ screen reader mode to navigate the page via landmarks. These regions should have a clear label and should be descriptive. The language of the label should not be technical like Carousel, chrome bar, etc. instead it should be related to the user’s task like primary navigation, main content, and so on.
Landmark types and usages:
We should not use all the landmarks to define a page, it should ideally be around 5 not more than 6.
- Banner: It includes the common global elements like the Company’s logo, top navigation, headers depends on the site or app.
- Navigation: There might be multiple navigation regions within a website page or for the app. The navigation region contains all the actions/links that are responsible for navigating the content for a page.
- Main: Main defines the primary content of the page like a list, group of charts or widgets, or an article with the primary content. There should be the main region defined if you are defining the landmarks.
- Complementary: It can be present as the secondary content of the page but it should have some meaning independent of the primary content or the main region.
- Search: Search combines the search suggestions/type ahead and other elements that define the search functionality for a page. Search is the only region where it can be combined with the Banner or Navigation region. In general, all the regions should be independent of each other.
- Content-info: Content info is used to define the footer region of any page.
- Form: Form is used when you have a combination of different inputs that create a form and it is not appropriate to use other regions like main, search, etc. it can be defined as Form region.
- Region: It is used to provide a generic landmark for people to be able to navigate easily when none of the other landmark roles are appropriate.
6.Headings:
It helps visually impaired users to form a mental model of the hierarchical structure of the content. There can be multiple levels of headings inside the content. Headings can be navigated through pressing ‘H’ in screen reader mode. There should be only one main heading “H1” for the title of the page.
All the other sections headers can be defined in the H2, H3, H4..H6 manner depending upon the content of the page.
The above 6 fundamental elements will define the accessibility spec which will be given to the development team to execute the functionality. An ideal way is to have all the components with accessibility compliant features so you just need to define the keyboarding sequence and the labels for a screen reader.
Measuring the success for accessibility:
It is important to define the experience level for measuring the success of how accessible is the page or the app. There are accessibility guidelines that are used to provide a rating for the app/web page based on the testing results. It depends that how good the experience is in terms of accessibility as we move up to higher ratings.
Compliance and grading:
According to the WCAG(Web content accessibility guidance), the experience of the accessibility can be standardized through the grading of the product. After the testing of any product based on the accessibility principles, they are given grades.
There are mainly 3 levels of grade:
- Grade ‘A’- It is the minimum grade required to be accessibility compliant for any product. In some organizations, it is defined as grade ‘C’.
- Grade ‘AA’- It is considered as the user-friendly experience and it’s expected to have minimum this level of experience for the products which have a very broad set of users. In some organizations, it is defined as grade ‘B’.
- Grade ‘AAA’- This grade is the highest grade a product can achieve and this indicates that the product has exceptional experience from the accessibility perspective. There are very few numbers of products that have achieved ‘AAA’ grade. In some organizations, it’s defined as grade ‘A’.
Reference from: WCAG
We need to learn these fundamentals and understand that there is always more to design to make the product more inclusive. I have been practicing this for a while now. I do the accessibility check on any design feature or interaction at least once during the ideation and feasibility step. This makes the overall product more inclusive and accessible.
We all can start adding value by taking these small steps. It will bring smiles to the people who need it the most and bridge gaps in their product experience.
