eBay created the Include—Accessibility Annotations Figma plugin to help designers with accessibility considerations early in their project, and to help with designer-developer collaboration. It is available to the Figma community and free. eBay teams use an internal version.
Headings provide a structure for the content within a screen. They help to divide up content and summarize it which can help users find and understand the content. For screen reader users, when an app uses headings, these provide an additional way to navigate around a screen. Typically, more prominent and heavier text should be for headings, but headings are more about structure than visual appearance.
Some differences in Android or iOS native apps compared to web: there is no concept of heading levels (and therefore no nesting) and describing the main purpose of a screen is typically done with a title in the navigation bar, rather than a heading.
Grouping elements like the contents of a tile or cell can make for a better experience when using assistive technology. If there is no action, or a single action, the grouping makes navigating the screen easier, as it reduces the number of swipes or presses. When more than one action is in a group additional annotation will be needed to explain the expected behavior.
Images that convey meaning are considered informative. Informative images need alternative text that screen readers will announce to communicate the image's purpose, function, or content.
Images that do not convey meaning or are non-functional and adjacent to onscreen text that conveys their meaning are considered decorative. Decorative images do not need alternative text.
To ensure the experience can be used by those with low vision, colorblindness and others, text, interface controls and informative graphic elements must meet contrast minimums.
Native apps need to support users who modify text size through the display or accessibility settings in Android or iOS. At different text sizes check for:
When actions can be performed with a gesture, ensure there is at least one alternate way to perform this using one finger and taps. As this requirement supports sighted users with limited dexterity but who may not be using assistive technology, the alternate method must be visible. Custom actions can also support assistive technology users.
For example, if the app has ‘swipe to delete’ functionality, to remove a row, provide another way, such as tapping an ‘edit’ button, tapping to select the item, and tapping a ‘delete’ button. Additionally, the app could support custom actions on the row, enabling assistive technology users to delete, while focus is on the row.
Larger touch areas make it easier for people with limited dexterity or low vision to activate controls, and to avoid inadvertently activating adjacent controls. The target area could be the size of the element itself or the element and its padding.
Recommended minimum: 48px x 48px unless target is in a sentence or block of text, or a pin on a map, or dots on a chart.
Drawing target areas helps to identify whether these meet the minimum size. Include then checks for any overlapping areas to ensure there is sufficient spacing.
Drawing the target can also help to communicate to engineers design intent on which areas will be actionable. E.g. is the row the target or only the button at the end of the row.
Color can be very beneficial for some users with disabilities, but use color as a secondary affordance of information.
Differentiating between colors can be very difficult for people with low vision or color blindness.
Do not rely on color alone to convey meaning or distinguish visual elements. Review designs in grayscale or monochrome to verify that the hierarchy and purpose are perceivable without color.
