Web Accessibility Roundup

This is a summary of my notes taken during a Web Accessibility seminar hosted by Hackforge and taught by Jason Pomerleau. This is mostly in short-hand and only touches on main/common topics.

WCAG 2.0 is the baseline standard. Level AA is what most legislation targets.

Common Considerations

  • Visual Impairment
  • Colourblindness
  • Hearing Impairment
  • Mobility/Tremors
  • Cognitive Impairment
  • Seizures/Motion Sickness

Visual Impairment

  • Zoom/font size changes. Ex does it still function at 150% zoom.
  • Screen reader compatibility
  • Focus highlighting – can you see what is active
  • Keyboard navigation
  • Font choices – are they clear and easy to read?

Colourblindness

  • Colours that convey information can’t be the only way of getting that information
  • Foreground/background contrast
  • Text colour / fidelity

Hearing Impairment

  • Captions for video/animation
  • Transcripts
  • Playback speed adjustment
  • Notification sounds – should not be critical to hear these. Not too loud.

Mobility Considerations

  • Keyboard Navigation
  • Ensure drop downs stay open on click (not hover only)
  • Dropdowns that need VERY precise mouse movement – ex toggle is tiny

Cognitive Impairment

  • Font choices
  • Reading comprehension level. There are tools that can grade your writing on it’s complexity and reading level.
  • Language barriers. Browser translation tools – can they work with your content?
  • Text inside images can’t be copy-pasted into translation tools.
  • Use of acronyms or niche terminology that isn’t explained.
  • Ableist wording (ex “it’s easy to do X” = it might not be easy for everyone).

Seizures/Motion Sickness

  • Strobing/flashing lights are very problematic
  • Excessive motion or animation
  • Transitions or text movement
  • Blinking text or indicators
  • Movement behind text

Structural Accessibility

  • The realm of the developer.
  • Built in the template/layout etc.
  • Unlikely to change without developer involvement.
  • Easiest to build in from the start.

Content Accessibility

  • Typically not involving developers.
  • Can easily slip out of compliance.
  • Requires training of content creators.
  • Should be part of the business processes.

Key Considerations

Headings

  • H1 to H6 tags should always be in correct hierarchical order.
  • Used by screen readers for navigation. Can jump to sections.
  • Should only have a single H1 tag. At the template level. It’s the title of the entire page. Content managers shouldn’t be able to create adhoc H1 tags.
  • Don’t use headings for font/emphasis purposes only.
  • Don’t just use big bold text – use actual heading tags and style them.

Images

  • Most common area for mistakes.
  • Alt text can help or harm.
  • In WordPress alt text is set in the media manager.
  • Screen readers announce the alt text as if it is part of the text. It says “image” before saying the alt text so you don’t have to repeat this by saying “image of” or “photo of”.
  • Alt text shouldn’t just describe the image, but also convey the info the image is trying to convey.
  • Context matters. Some images might need different alt text in different locations/uses.
  • If the image is decorative or repeats info already in the text = no alt text.
  • Decorative images = design, stock images, backgrounds, eye candy. Use empty alt text.
  • Don’t leave the alt attribute out. Make it an empty string. This is intentionally flagging it as decorative.
  • Informative images = convey information, impression or emotion. Labels for other information.
  • Functional images = linked logos, icons, buttons. If text accompanies the image = no alt text. If the icon is the only info then use alt text. Ex “print this page”.
  • Images with text = ideal is to put html text with the image then treat the image as decorative. Or communicate the information.

Image Tips

  • Don’t be vague.
  • Don’t say “photo of” or “image of”. Screen readers will say that already.
  • Never use the image filename or id as or in the alt text.
  • Tell the missing part of the story that the image conveys.
  • Don’t repeat a visible caption.
  • Captions are great for low vision users who don’t need screen readers.

Document Structure and Layout

  • Identify lists of navigation links with the html <nav> element or by using ARIA Navigation attributes.
    • Note – don’t put role=”navigation” on menu <ul> elements. Accessibility scanners will flag this. Put it on a div wrapped around the list or wrap a <nav> element around the menu list.
  • Identify body content with the <article> element or by using ARIA Article attributes.
  • Modals and overlay dialogs should be properly identified and focus within them managed. Refer to the ARIA Dialog information.
  • See more information about ARIA Roles.

Text Accessiblity

  • Don’t use all capitals. Use CSS to make text uppercase because screen readers treat all capitals as acronyms.
  • Contrast – aim for a minimum of 4.5 to 1. (https://contrast-ratio.com).
  • Less than 12pt or 16px font size is difficult for users.

Links

  • Avoid “click here” language.
  • If the surrounding text was gone would the link still make sense?
  • Open in same tab unless going to a different website or opening a downloadable file.

Documents

  • Most document formats are not accessible. PDF is really bad.
  • Just create web content instead.

Video

  • Captions – automatic vs manual. Automatic is better than none. Manual is better than automatic.
  • Add a transcript below or with the video.
  • Alternative content format for important info.
  • Don’t use ‘fake’ captions – video overlays within the video are visual only.

General

  • Don’t use colour only to convey information.
  • Use semantic HTML. Don’t use divs for navigation elements. Use nav and list elements.
  • Don’t reinvent native controls – like making your own checkboxes. These are very poor for accessibility and even cross-browser compatibility.
  • Labels on form inputs.
  • The role of the title attribute is unclear – there is not standardized agreement. Not a replacement for alt text. Don’t duplicate alt text into the title.
  • ARIA attributes: only use when necessary. Semantic HTML is better!
  • Tables should only be used for tabular data. Always have a table heading (TH) element at the top.

Scanning Tools

Evaluating Accessibility

  • Automated scanning tools lack context, but can be useful in the hands of a professional.
  • Consult with users who are willing to review or give feedback.
  • Start somewhere – are you doing better than you did last month?

Posted on Posted in DevelopmentTagged , ,

Leave a Reply

Your email address will not be published. Required fields are marked *