Skip to content

Latest commit

 

History

History
147 lines (94 loc) · 10.8 KB

accessibility.md

File metadata and controls

147 lines (94 loc) · 10.8 KB
Raw

Guides

WAI-ARIA Authoring Practices Inclusive Components The A11Y Project

Buttons

Disabled

Whenever possible, don’t use disabled buttons. Let people click it at any time and, if necessary, show an error message as feedback. Source

Tooltips

Inclusive Components Tooltips in the time of WCAG 2.1

Aria-live

Using aria-live More Accessible Skeletons

React

Usefull resources

Libraries

Component libraries that include many usefull components without styling (menu / dropdown, listbox, modals, popvers, etc)

Utilities

Browser Extensions

SaaS

Resources

Figma plugins

A11y testing groups

Screen readers

  • NVDA
  • JAWS
  • VoiceOver (macOS only)

Articles

Notes

First rule of ARIA

Don't use ARIA

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state or property to make it accessible, then do so.

From W3C Docs

It's unfortunately easy to use ARIA wrong and it can really screw up the accessibility of a page if used incorrectly.

Keyboard interactions

Not every element needs to be keyboard-interactive. Screen readers have dedicated commands for headings and landmarks (among other things), so tabindex isn't necessary for those items.

Tabindex

  • 0 - make focusable (order by DOM)
  • -1 - make unfocusable (still focusable by JS)
  • 1+ - DO NOT USE (it will change the order)

There are some established conventions with keyboard access, such as binding the Escape key to close a dialog and return to a triggering button element. Before trying to invent patterns for keyboard access based on a new design that was passed to you, do some research on common conventions using the W3C's ARIA Authoring Practices Guide and/or Inclusive Components from Heydon Pickering

Accommodating users' needs with optional settings is one thing, but allowing enough time is another entirely. Don't assume all users will see something flashing across the screen before going away automatically, such as a Toast or other notification. Keep dialogs and other temporary layers on screen until the user has time to navigate to them with the keyboard and close by activating a button to confirm, close, or some other intentional action.

Accessibility is impacted by UX and design

There are a couple of comparisons that could help to understand how design and accessibility relate to one another. First, accessibility is like blueberry muffins: you wouldn't make them by shoving the berries in after baking (paraphrased from Cordelia McGee-Tubb). You also wouldn't "take a condemned home and put new siding on it to successfully pass building code" (Shell Little).

The most inclusive websites and web apps consider accessibility as part of the design process (and earlier, such as in requirements gathering). This is often referred to as "shifting left", where the responsibility for accessibility isn't left to developers or QAs to identify and fix alone. Keeping this ideal process knowledge in mind can be helpful when working with your colleagues in different disciplines. As a developer, you shouldn't be on your own to implement accessibility–even though it happens quite often.

Design tips

  • Anything a mouse user can do, a keyboard user should be able to accomplish as well (sometimes with an alternative function, or "affordance"). Keyboard support has the added benefit of supporting assistive technologies quite often, making it a base requirement for any interactivity.
  • Visual treatments should have enough contrast and not rely on color alone. This applies to links and text over backgrounds, data visualizations and legends, and product color pickers in e-commerce. Use underlines, text labels, and patterns along with colors that meet WCAG contrast requirements.
  • Designs could annotate accessibility information for non-visual mediums like screen readers, such as suggestions for semantics/structure and alternative text for images. This could note intent for markup like headings, links, or buttons; ARIA roles and widget patterns; focus/tab order; and responsive/flow details.
  • Motion, animation, and autoplay can make people sick and should be employed responsibly. Have conversations about necessary movement in designs to determine the most accessible ways forward that respect humans. You can also use the prefers-reduced-motion CSS media query.

Motivating stakeholders

To convince people with different mindsets to adopt accessibility, sometimes you have to employ different strategies. By approaching with curiosity, you could learn more about what would motivate someone the most.

Some will respond to a cool factor, like dangling a carrot, because they are inspired and encouraged to do the right thing with more information. "I can make a beautifully-designed component that works with the keyboard and screen readers? COOL!" These personalities are examples of when accessibility education and awareness shared with a spirit of collaboration and humility can accomplish wonderful things. Carrots. Accessibility that goes beyond compliance to instill it as a core value can make your product more usable and competitive.

Others less motivated by altruism or innovation for accessibility may require more of a stick approach, such as a legal requirement or financial risk. They may respond to competitive pressure, potential missed sales opportunities, or the cost of design and technical debt. You could stress with them the impact on budgets and timelines to redo a project or defend it in court for accessibility, which are significant. There is also the issue of missing revenue from people with disabilities who are excluded from using an inaccessible website or app. Share this with folks concerned with finance: the total after-tax disposable income for working-age people with disabilities in the US is about $490 billion, which is similar to that of other significant market segments, such as African Americans ($501 billion) and Hispanics ($582 billion) according to the American Institutes for Research (AIR).

List of legal policies Voluntary Product Accessibility Template (VPAT)

Estimation

Estimation in software development is hard. It can still play a useful role for accessibility in your projects. By estimating the time necessary to make components accessible from the start, you can quantify what it will cost to deliver quality work on time. You can also compare your up-front estimates to the impact of a total rewrite post-launch: the dreaded "what would it take to make this app accessible?" Because accessibility has to be considered throughout the software development lifecycle, rewrites can inflate budgets into something much more costly than what it would have taken to build it right once.

Enterprise teams recommend padding estimates by up to 30% to give accessibility the time and attention it requires. It's possible your organization could be more lean and efficient at achieving accessibility. However, this could be a good first metric to make sure your project meets expectations with varying accessibility expertise among team members. Aim to underpromise and overdeliver. You can always improve your estimates as an organization over time.