Skip to content

Instantly share code, notes, and snippets.

@jennceng

jennceng/a11y.md

Last active December 20, 2018 16:00
Show Gist options
  • Save jennceng/82974527150e4ecf90d93d11ca0305ac to your computer and use it in GitHub Desktop.
Save jennceng/82974527150e4ecf90d93d11ca0305ac to your computer and use it in GitHub Desktop.
Download ZIP
Web Accessibility (a11y) Guide
Raw
a11y.md

Table of Contents

Terminology and Goals
Screen Readers
Dope Tools
Common Pitfalls
Actionable Goals
Keyboard Navigation
Screen Readers
Intentional Visibility Control
Color
Focus Control

What is this?

  • an evolving place where I am storing knowledge about WebAccessibility as I start and continue my journey to become a more empathetic developer

Where is this info from? Where can I learn more?

  • these sources have been invaluable to me, though they are part of subscriptions the creators have free sources as well:

Terminology and Goals

  • Acessibility can mean a lot of things, this general guide / list of resources refers to *WebAccessibility - *The use of the Web by people with disabilities
  • Accept that we as developers have made and will continue to make mistakes, but always strive to do better and build empathy to keep all users in mind when designing and developing
  • Web Accessiliby Initiative- WAI - part of W3 (World Wide Web Consortium)
  • Three levels of compliance: A, AA, AAA
  • ARIA- Accessible Rich Internet Applications

Dope Tools

How People Access Your App

  • As developers and designers we will often think of people using our app for example with a mouse / trackpad for precision and a keyboard for data entry or their mobile equivalents
  • We should especially keep in mind users who use / have:
    • Keyboard-only interaction
    • Screen Readers
    • Mouth sticks / head wands
    • Single Switch
    • Low vision
  • Interestingly for MAC users when using assistive technologies the most common screen reader is Voice Over + Safari which tends to work better on macs for voiceover

Common Pitfalls

  • I’m definitely guilty of pretty much all of these
  • essentially the reason we often fall into these is because HTML semantics are accessible but often do not look great or behave percisely the way we want, so we often do things like creating our own “checkboxes” but forget to add back a11y
  • always better (less prone to a11y bugs) to go from the native html and customize it than to go from a plan span or div and try to build up a11y as it is often not obvious what semantic HTML gives for free
  • HTML semantics are actually super important for a11y, things like Screen Readers know what to do when they come across a ​<button>​, but often due to the styling that comes with buttons and such we use things like ​<div>​ and <span>​ with custom css to get things looking the way we want
  • a good rule of thumb is to use the correct HTML tags and override unwanted css
  • example going from a “div” button to a fully accessible button
    • here we had to add the btnClicked callback to onKeyUp as well (which would have to include checking the key press is a spacebar or enter key), it is non-obvious but for semantic HTML buttons an onClick callback is also fired for key presses
<div class="button">Click Me</div>
<!--accessible version-->
<!--Role doesn't add functionality but lets a screen reader know it's a button that is focusable-->
<!--tabindex allows keyboards to tab to it-->
<!--because it's a div has to add a keypress event handler-->
<div class="button" role="button" tabIndex="0" onClick="btnClicked()" onKeyUp="btnClicked()">Click Me</div>
<!--semantic a11y compliant, add desired css if default styling not wanted -->
<button onClick="btnClicked()">Click Me</button>
  • Visible Focus
    • folks often do not like the default focus state on browsers and remove it, if you do make sure you replace it with a different design
    • folks often make their own checkboxes
  • Another non-obvious one is correctly using H1 tags, <a> tags, etc.
    • for keyboard only users, in order to have more options than just tabbing through an entire site, they can also parse sites through things like <h> tag hierarchy (h1 indicate higher importance, etc.) or parse by links, etc.
    • let’s see this in action!
      • MAC users
        1. navigate to https://www.theguardian.com/us
        2. active Voice Over
        3. turn on Rotor with ctrl + option + u
        4. use left and right arrows to see different elements you can parse by
    • tldr here is these tags are not just here for us to make text bigger or smaller, they have actual implications for how a site can be parsed

Actionable Goals

Mac users: using voice over and safari do a quick audit of your app to see if everything can be navigated / interacted with via keyboard and if Screen Readers are picking up what you expect and giving succinct and helpful speech

Run your app through Chrome auditing for accessibility on multiple screen sizes that you expect users to behave with

Add a static tool like React a11y

As you design and build new features keep a11y in mind, before releasing them to production test with assistive technologies

test if during things like filling out forms incorrectly if assistive technologies able to inform users

Starting with achieving A level compliance, use tools like webaim checklist as a guide and the WCAG guidelines for a more comprehensive set of requirements

If you’re feeling ambitious, add a a11y check to your CI that restricts features from being released if they do not meet certain standards

Keyboard Navigation

  • Two main goals: Can everything be done ont he keyboard? Can they get done relatively quickly (how many keystrokes does it take?)
  • Keyboard Shortcuts: let’s take a look at
  • let’s take a look at an example!
    • navigate to your favorite twitter account
    • press “shift + ?”
    • you can see Keyboard Shortcuts that lower the needed keyshifts to do common tasks
    • usually vim-inspired :) nerds, amiright?
    • one thing to keep in mind if you make shortcuts is to not override browser shortcuts

Tabbable Elements

  • on any website hitting tab goes fwd one, shift + tab moves back one
  • most common tabbable elements
    • <a>
    • <button>
    • <input>
    • <select>
    • <textarea>
    • <iframe>
  • divs, uls, spans are not tabbable by default as their semantic html does not assign a particular purpose
  • anything you would interact with comes tabbable by default when using semantic html
  • you can make something tabbable by adding Tabindex (or making something that’s usually tabbable not)
    • negative means element should be focusable but should not be reachable via sequential tabbing
    • 0 means should be focusable and reachable in sequential keyboard tabbing
    • a positive valuemeans should be focusable and reachable, and its relative order is defined by the value similar to a z-index

Skip Link

  • strategy: when a user is tabbing into site for a bit we assume they may be a keyboard-only user and we reveal a skip link to help
  • go to https://www.nytimes.com/ and start tabbing around
  • you can do it a million ways but commonly you have an element not initially visible on the site using css ​top: -40px​ and when the element is focused on you make it ​top: 0​, that way it will be ignored by users using a mouse

Screen Readers

Forms

  • labels - important for screen reader to have somethign that describes the field, also helpful for focusing onto the input for users with lower dexterity
  • Aria-labelledby- helpful for forms with multiple elements / subforms
    • example use case: there is more than one field called “name”, one for the user and one for a subform of their emergency contact, one perhaps should be given aria-labelledby=“emergency contact”
  • errors - keep in mind form validation errors are rpesented in an efficient, intuitive, a11y manner
    • Ex: changing only the color of the label will not be helpful for folks who cannot distinguish a color change

ALT text

  • property of image element, without an alt-text it will read the src
  • when possible, images should have succinct alt text
  • **user generated content **
    • If possible perhaps give users an option to also provide alt text if uploading images
  • don’t use words “image of” or “graphic of” in alt text as screenreaders already insert this
  • TIP:
    • alt=“”​ attribute is to intentionally skip an element, for example if you can’t have alt text sucha s for user generated content so at least the name of the files aren’t being read aloud, or anything purely decorative or otherwise doesn’t add any meaning
    • alt=“UPPERCASE”​ will have the value read by individual letters, ex. if you wanted it to read M-I-T
  • screen readers do not read anything that is:
    • ​display: none
    • <… hidden />
    • <visibility:hidden>

How Visibility Strategies Affect Assistive Devices

  • Tldr: when hiding things make sure you pick the right technique and give a good experience to all users​
  • Display: none cascades done, it hides it from everyone including keyboard users screenreaders, etc., it’s removed from a11y tree
  • HTML5 ​hidden​ attribute is supported in some browsers and is equivalent Display: none
  • ​opacity: 0​
    • this reserves dimensions of the node but the content is not visible, if we tab through the page it will still be focusable for a keyboard user, you may need to do more work tehre, like a tabindex of -1
    • node is not exposed on a11y, but it’s children still exist on it, so a screenreader would still be able to reach it
  • ​style=“visibility: hidden”​ similar to display none but it reserves the pixels on the screen
  • class visuallyhidden with css
    • general idea of giving it dimension 1px but margin -1 pixel so you don’t see it
    • renders to screen and is hidden by CSS
    • can still be reached by a screen reader
    • keep in mind for a sighted keyboard user they will be able to tab onto something they can’t see which is not ideal
    • use case: text alternatives
    • don’t put anything focusable
  • aria-hidden="true”​ removes children as well from a11y tree
    • still takes up pixel space
    • dom tree is not affected
    • aka “ghost control”
    • use case: maybe not relevant to a screenreader
    • add a tabindex of -1

Focus Control

  • you can get the currently focused element at any time using ​document.activeElement​
  • helpful for things like when a user is about to bring up a modal, you can save the current active elements and use it for when the modal is closed and bring them back to where they were
  • Tabtrapping / Focus Trapping
    • Ex. you want your user to be able to tab on that modal while it’s open and not necessarily the stuff behidn it
    • strategy: grab first and last tabbable element, add an event listener for checking if their tabbing: if they are on the last item tab them to first item, and if they are on first item and they “shift + tab” take them to last item
    • for modals you may also want to make intuitive ways to exit it like clicking outside or pressing Escape button will close it

Color

  • When beginning to learn about a11y we often think of visual vs. blind users, but there’s a full spectrum, even a bit of consideration about others who fall into all of these categories can go a long way
  • Seizures: do not design content in a way that is known to cause seizures, such as a lot of flashing
  • Palette evaluators can evaluate your color choices to check for compliance, tools are also online for you to put in hex codes such as design of business cards, brandings, etc.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment