Permalink
Fetching contributors…
Cannot retrieve contributors at this time
414 lines (279 sloc) 18.1 KB

Accessibility for everyone - Laura Kalbag

Book review

  • Emphatically written
  • Gives a great idea how you can start making products more inclusive right now
  • Also gives a serious roadmap on how to work on accessibility in a team
  • Functional / technical advice in chapter 5 and 6

Notes

  • Often a11y features that seem to be meant for people with a specific disability benefit others as well. For example, when I watch Netflix I turn on subtitles in the same language. These subtitles might be intended for people with a hearing disability, but come in mighty handy when there's a lot of noise around. The point is, a11y features don't just improve your app for a specific group, it improves it for everyone.
  • Content creators should also be educated in making content accessible
    • headers
    • divide text
    • use alt text
    • descriptive links
  • When you update content with a non-user event (i.e. server request) it's important to notify the user. How do you handle screen-readers for example?
  • Color should never be used as the sole means of conveying information.

Universal design

“Universal design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design.

Excerpt From: Laura Kalbag. “Accessibility for Everyone.”

Screen Readers

Both OS/X and Windows come with their own screen reader. OS/X has VoiceOver and Microsoft has narrator. If you want to test a site with a screen reader, these can be quickly enabled.

4. Content and design

Alerts

In the rich web apps we create today, content can change without it being triggered by a user event. In this case users should be alerted of the change. Screen readers should be updated of the state change as well. Twitter is a good example of how this is done.

Error messages

Error messages should be expressive and make use of 'human language'.

Color

Color should never be the sole conveyor of information on the web, not even if it should actually convey a color. If you have a product with only color swatches, these swatches might be meaningless for people who are colorblind or otherwise visually impaired.

Rich Media

Images

All images that aren't decorative should contain an alt text. The alt text should be descriptive. For a picture of pancakes, an alt text with 'Pancakes' is a lot less useful than "Stack of blueberry pancakes with powdered sugar". It will let someone with a screen reader know that this isn't JUST a stack of pancakes. source

Text in images

In general a bad idea. Unless it's a logo but in many cases you could use SVG text.

Machine learning for alt text?

Graphs and infographics

Think of a structured way to present the information to screen readers for example. Prevent a text alternative.

PDF's

PDF's suck. The behaviour of clicking a PDF link is inconsistent across browsers and user settings. PDF's themselves aren't accessible.

Recreate PDF content in HTML to make it accessible and searchable. There are tools to do this automatically.

Use print stylesheets if content needs to be printable:

A generous user experience

Offering alternatives in your user interface is a great way to include more people. For example, having a video's transcribed will both help people with disabilities as attract people that prefer reading over watching.

5. Accessibility and HTML

The importance of structure

  • Writing well structured HTML is the base of an accessible website.
  • Check your HTML without any stylesheets and see if it makes sense. This is the raw content that screen readers go through.
  • Googles design and content guidelines greatly match accessibility guidelines
  • Using only one H1 on the page still seems like the way to go.

Lists

Screen readers will read out 'bullet' on an ul or the number of an ol item, even when these are hidden in CSS.

Forms

Overriding default form elements often results in loss of accessibility features.

Inputs

All inputs have default accessibility features

Labels

Labels should not be omitted for placeholder texts. Labels are an important part of forms and make them descriptive and accessible.

Be clear if a form input is required. Adding an asterix to the label is good. Adding the word 'required' is better.

Label and input pairing

Each input should have a unique ID and each corresponding label should have this ID in it's form element. This pairs the input and label for screen readers, but also brings advantages for regular browsers. When you click a label, the matching input will automatically be in focus in most browser.

Buttons

Make the different states distinguishable.

Keyboard navigation

Shortcuts

  • Can be very helpful for people using screen readers. Check Twitter for a good example
  • JavaScript shortcuts don't work with Windows screen readers. Interesting read: Time to revisit the access key?

Skip links

  • Used to quickly skip a bunch of links (we knew that)
  • Often aimed at screen-readers and hidden off screen (we did that)
  • Shouldn't be hidden because it's mostly useful for keyboard navigation
  • The keyboard focus should also skip. This is not the default behaviour in Chrome and Safari at the moment

Keyboard focus and visual focus

  • The visual focus is whatever is visible in the viewport
  • Keyboard focus / element focus is the focus of a specific element
Focus and hover styles
  • Links, buttons and inputs have a tabindex and focus style by default
  • Focus styles are indispensable when using keyboard navigation
  • Don't rely on hover styles (mobile and such)
  • Making a default div interactive can be confusing for screen-readers and user navigation (As reordering content with CSS for example)
tabindex
  • tabindex is honored when navigating with the Tab button

  • tabindex is ignored when navigating with cursor keys

  • In general it's advisable not to change the tabindex

  • Use tabindex=0 to tell keyboard navigation to recognize an element in the tab order. This can be used to make a (normally) non-interactive element reachable with the Tab button.

  • Use tabindex=-1 to remove an element from the tab index. This can be used to fix the 'skip link'

The tabindex has it uses but is not totally reliable and only influences keyboard navigation.

Separating structure and style

WYSIWYG editors

  • Often a culprit of bad HTML structure as they're made to change appearance, not structure
  • Limit WYSIWYG editor options and instruct users

CSS styling

  • Beware of re-ordering things with flexbox or css-grid as this is only applied with CSS and has no semantic meaning.
  • Don't style an element to look like another one but use the element intended for the purpose (buttons/links/headers)

Meaningful HTML

  • Separate structure and style
  • You can offer alternative styling for enhanced viewing options (think of Safari's 'Reader view')

Progressive enhancement / graceful degradation

  • Progressive Enhancement: Start with the most basics, accessible to everyone and build up experiences from that point on
  • Graceful degradation: Take the most capable browser as starting point and implement fallbacks

WAI-ARIA

  • Stands for Web Accessibility Initiative - Accessible Rich Internet Applications. Often referred to as ARIA.

  • ARIA is a relatively new standard (March 2014)

  • Allows developers to assign different roles, states and other properties to make it easier to describe their behaviour in HTML

  • Can possibly enhance the native meaning of HTML elements

  • WAI-ARIA on MDN docs

Roles

  • HTML attribute: role=
  • Used to define page structure when HTML elements are not clear enough or to emphasize their meaning
  • All about WAI-ARIA roles on w3c.org
  • Don't tag role= to just anything, make sure that it makes sense

Landmark Roles

States and properties

When to use ARIA (and when not to)

  • ARIA doesn't replace well structured HTML

  • ARIA won't make an unusable website usable

  • ARIA W3.org guide

6. Evaluation and testing

Make A plan

  • Create a test plan containing
    • testing methods and when they'll be used
    • how testing methods support production team towards targets
    • how results are documented
    • how results fit in the feedback loop

Heuristics and analysis

  • Heuristic evaluations: Testing an interface against a set of guidelinces (WCAG)
  • Cognitive walkthrough: Test the interface against specific tests, possibly emulating particular setups
  • Don't wait with testing until the end.
  • Possibly use something like Tenon API - https://tenon.io/

Device and browser testing

Testing suite:

  • Desktops running all major OS
  • latest version of all major desktop browsers
  • mobile devices running major operating systems (android is fragmented, use several versions)
  • major browsers across mobile OS'es
  • assistive technologies including screenreaders (JAWS, NVDU, oiceOver, Window-Eyes, Windows Narrator, ZoomText)
  • Keybord navigation
  • Accesibility settings like zoom and magnifiers

Validators and checkers

Color and contrast checkers

Readability checkers

  • See resources

Emulating connection speeds

Testing keyboard navigation

Usability testing

Finding participants

  • Always include people with disabilities and impairments
  • Choose testers that are comfortable in using the tools they're testing with (people who can teach you)
  • Be careful about categorizing and grouping people with disabilities

Running tests

Ongoing testing

  • Testing deosn't end on launch day
  • Consider adding form or feedback button

7. Laws and guidelines

European Accessibility Act

Guidelines

  • WCAG

Testing Matrix

Questions

  • How accessible is 'infinite-scroll' for adding new content? (or how could you make it accessible?)

Resources

Accessibility tools and websites

Articles on accessibility

WAI-ARIA links

HTML5 accessibility

Accessibility checks

Screenreaders