Accessibility quick wins are modifications that take a short amount of time to implement in your application as a first step to making it more accessible for all.

Alt-text in Images

All visual and non-text elements (images, GIFs, graphs, charts) in your application should be accompanied by alternative text (alt-text for short), which is text that describes your non-text elements in detail, providing necessary context for assistive technology users.

A11y Actions:

  1. Add the alt-text attribute to all your image elements, for example, Two kittens playing with a ball of yarn
  2. Alternatively, write detailed captions under your non-text elements
  3. For purely decorative images on a page, consider adding an empty <alt=""> attribute so screen readers can skip them altogether

Resources:

Animations

As an application developer, it is important to honor system settings. In-app settings are ok too, but should be superseded by system preferences that a user has already specified.

Animations on the web and mobile have been known to trigger seizures, induce nausea or trigger headaches and more. It is also not uncommon for users to turn animations off to meet their preferences, for example, optimize their device performance or save battery. As such, it is important to incorporate animations in a way that is inclusive of all without causing harm.

A11y Actions:

  1. Adopt the three flashes or less recommendation from WCAG, which stipulates that your animation should not have any more than a maximum of three flashes in a one second period.
  2. Give users full control of the animations in your application, so that they can pause the animations, stop the animations or hide them from a page altogether should they prefer to.
  3. Where user interaction on a page i.e. scrolling up and down triggers animation, add provisions to disable or reduce this motion-induced animation.

Resources:

Buttons

Buttons are an important way to deliver calls-to-action to your application’s users.

A11y Actions:

  1. Icon-only buttons should include button labels to provide context around button actions.
  2. Disabled buttons are often used to communicate that an action needs to be completed first before moving to the next step. However, disabled buttons are inaccessible to screen readers and often, it is unclear to an assistive tech user what the final outcome of completing a couple of steps is. Adding labels that describe why a button is disabled and what needs to happen to enable it is a good first step.
  3. With button sizing, make sure to provide a large area for user interaction, for example, in iOS the minimum touch target size is 44x44 points, and in Android it is 48x48 points.
  4. Consider using in-built button elements by default (on the web as well as on mobile) as they have predefined styles and a11y features like touch target size, tab focus, focus highlight and interaction shortcuts (not everyone uses a pointing device to interact with components) written into them.

Resources:

Color Contrast

Color contrast is a measure of how different colors are from each other - colors that are opposites have the highest contrast and those that are next to each other on the color wheel have the least contrast.

A11y Actions:

WCAG recommends that

  1. the color contrast between background and foreground elements should have a 4.5:1 contrast ratio,
  2. icons for user interfaces that are essential should have a 3:1 contrast ratio.

Resources:

Headers

Page headers are primarily how screen readers and other assistive technologies navigate pages on the web. Correctly identifying page headers makes it possible for assistive technology users to get a quick overview of what’s on the page and jump to the sections they are interested in.

A11y Actions:

  1. Use HTML markup to identify page headers. For example, here are guidelines on using the <header> element on the web
  2. Organize your headers hierarchically, being careful not to skip levels i.e. H2 should come after H1, do not skip to H3 or H4 after H1.
  3. On native mobile apps, you can also configure anything that represents a header as a heading to let the users quickly explore what the screen has to offer and speed up navigation, by jumping from one to another with a simple gesture.

Resources:

Modality

Modals are pieces of information that pop up, and are commonly used to nudge a user to complete a specific action, or to provide more information.

A11y Actions:

Because modals are informative but also disrupt the flow of information on a page, it is important to give the user full control over opening and closing modals throughout your application. An accessible modal is one that

  1. provides the right information to screen readers
  2. manages keyboard focus properly You can use HTML and ARIA to serve semantic information and work with JavaScript to change behavior and CSS to dictate appearance.
A common mistake with modals in applications is that the focus doesn’t move to the modal or if it does, focus remains on the content underneath the modal. Be sure to test your application modals and fix this behavior where it occurs.

Resources:

Multimodality

Important information should be conveyed in multiple modes, that is - color, haptics, sound, through messages and iconography - so everyone can perceive it.

For example, consider a text box in a form that is highlighted in red when the user enters invalid information: colorblind users may not perceive it and screen reader users may also miss it if it is not actively configured by developers. Adding some messaging next to it with specific information on why the information entered is invalid and how the user can fix it, will make it much easier for everyone to identify. Redundancy helps in this case. The more modes your information is presented in, the easier it will be to understand.

Resources:

Order of Actions

If your application presents the user with a choice of actions at any point, be sure to present the least destructive option first from the range of choices, for example, when asking the user to confirm their selected action to delete a playlist, the OK option should be highlighted first instead of the CANCEL option; or if you have CANCEL and CONFIRM as options for the user to pick from, highlight CANCEL first because remedial actions are easier (when one cancels, they can redo a task.

For time management reasons, should a user select CANCEL, consider returning them to the most-recent state i.e. to the populated version of a form rather than discarding all their input.

Resources:

Share Buttons

Providing ways for users to share your application across different social media is one of the most common ways to spread the word about your application and draw users’ attention to it. A minimalist / common approach is to use hyperlinked social media icons to achieve this.

Accessible icons are images which can be accessed equitably and whose function can be understood clearly by all application users. To make your icons accessible:

A11y Actions:

  1. Add alternative text to your icons that describes their purpose i.e. what to expect on click. For further reading on alt-text best practices, see the images and alt text section.
  2. Choose icon colors that have high contrast to your background and see the color contrast section for more detailed best practices.
  3. Provide clarity by including accompanying on-screen text, usually a one-word descriptive label, next to your icons.
It is an accessible practice to include either alt-text or associated on-screen text with an icon.

Resources: