kylefang/polaris-react
1
0
Fork 0
mirror of https://github.com/HackPlan/polaris-react.git synced 2026-01-12 22:44:36 +08:00
Code Issues Packages Projects Releases Wiki Activity
Files
hackplan
polaris-react/documentation/Accessibility.md
Devon Persing 0ce00c8916 Typos and bullets 
Fixing typos, tweaking language to be more consistent, and nesting
2018-09-14 10:54:35 -07:00

11 KiB
Raw Permalink Blame History

Make commerce better for everyone!

At Shopify, we want to create inclusive experiences for all our users. We don’t want to limit who can use our product, and who can access our merchant’s products. We should set a high standard for usability.

Looking for a testing checklist before you submit a pull request? See our accessibility testing guide.

Did you know that:

  • ~3–10% of people worldwide have vision problems (low vision, no vision)
  • ~4.5% of people worldwide have one form of colorblindness
  • 8% have some mobility problems (for example may not be able to use a mouse or keyboard)
  • 6% have cognitive disabilities (for example require clear instructions and well-ordered content)
  • In Canada, vision loss is expected to increase nearly 30% by 2024

Overall:

  • About 1 in 7 Canadians have a disability of some kind
  • About 1 in 5 Americans have a disability of some kind
  • About 1 in 7 people worldwide have a disability of some kind

Sources: Summary Health Statistics for U.S.Adults: National Health Interview Survey, 2011 (PDF), Colour Blindness Awareness, CDC: 53 million adults in the US live with a disability, Accessible Canada - Creating new federal accessibility legislation: What we learned from Canadians, World Bank Disability Inclusion

Accessibility 101

For those looking to skip ahead, check out our own best practices.

The technical standards for accessibility come from the Web Content Accessibility Guidelines (WCAG). For a number of years we’ve been working with WCAG 2.0, but as of June 2018, WCAG 2.1 is the new recommendation. WCAG is an ISO standard, too!

WCAG includes recommendations around how users, especially those with disabilities, expect to interact with websites, including complex web apps. These standards are designed to make websites work correctly with a wide variety of assistive technologies, such as screen readers, high contrast and magnification tools, speech recognition software, custom input devices. They also help to support users who have trouble with memory, attention, reading, color, information processing, and other similar issues.

If you work on mobile apps, you might want to take a look at the Mobile Accessibility guidelines related to WCAG. Vendor guidelines for Apple and Android apps also include accessibility recommendations and requirements.

There are a ton of resources to learn about accessibility in general. The following is a curated list of the ones that are most readable, up-to-date, and relevant.

It’s also important to think about accessibility as a design and usability issue, not just a technical issue. We Are the Original Lifehackers outlines how design is improved when people with disabilities participate.

Implementation best practices

  • Color contrast should be sufficient

    • light text on light backgrounds can be very difficult to read (for example outside on a sunny day, on a glossy monitor, after staring at a screen all day)
    • check contrast with Tanaguru Contract-Finder or a similar tool and aim for a ratio as close as possible to 4.5 — this includes copy, headings, and form fields
    • all should stand out from the background — be especially careful when setting text against a noisy background image

  • HTML is valid and semantically correct

    • heading levels follow hierarchy (<h1> > <h2> > <h3>)
    • all form inputs have a valid label — <label for="INPUT_ID"> or fallback
    • if not pointing to a URL, use a <button type="button"> element for your interactive controls

  • Strive to make features work with a keyboard alone

    • keep focus outlines on links and toggles, without these, it is impossible for keyboard users to navigate — the outline can be customized if the default style isn’t preferred, though keep in mind that the default comes for free!
    • update focus as new content is revealed (for example auto-scrolling to new page section, updating filtered results, opening a modal window)
    • bind esc to quickly cancel modals, popups, and similar interactions
    • put your mouse away, what happens? At the very least, the site must be navigable, forms can be manipulated and submitted
    • whatever happens on hover, should also happen on focus — this includes styles and JavaScript functionality

  • Don’t make users guess what to do next when it comes to forms — have clear, informative error states that detail next steps

  • Icon-only buttons should have screen reader friendly titles so they make sense

    <button class="icon icon-close" type="button">
  <span class="visuallyhidden">Close Menu</span>
</button>

  • Meaningful content isn’t hidden inside <img>, or :before :after elements which are unavailable to screen readers

  • Any ARIA roles must be tested on Voiceover & NVDA before shipping

    • if not tested, we don’t know if they’re helpful or not
    • if unsure, ask for help or leave it out, ARIA that’s untested can make things worse
    • you should automatically check for issues using a tool like WAVE in order to validate the WCAG compliance
    • tips on NVDA with VMWare 1, 2

  • All of the above counts for mobile as well — iOS and macOS have VoiceOver built in, and there are many awesome apps that create new possibilities for the blind

Testing

Curious about testing yourself? The best thing is to manually test your pages with a keyboard only and fire up a screen reader to test for yourself. Automated tools can be useful but are usually for catching trends and low-hanging fruit like missing alt attributes. Here are a few recommended testing frameworks:

Tools and resources

Test tools

Patterns and design systems

Books and online courses

Mobile resources

Legal

For regulations around the world. These are long documents often written in legal-ese, not recommended as a place to learn about accessibility, but valuable for anyone interested in regulation and how it can be used and abused.