Accessibility Anti-Patterns with AbilityNet

AbilityNet Live logo

Image of Dafydd Henke-Reed

This free webinar took place on Tuesday 18 August 2020, 1pm BST

Dafydd Henke-Reed, Principal Accessibility and Usability Consultant with AbilityNet spoke about Accessibility Anti-Patterns.

When developing for the web, even with the best intentions, accessibility can become a vortex of inelegant code, functionality that does not degrade gracefully, and localisation nightmares. Dafydd's talk discussed what happens when accessibility goes wrong. It provided "war-stories covering immense and monstrous websites, and how they got stuck in digital swamps."

Viewers gain an understanding about how to promote productive accessibility and expert advice to help you avoid falling into traps when making accessibility improvements.

Watch the webinar recording to learn about:

  • Kitchen sink accessibility
  • Behind-the-scenes accessibility
  • The risks of bolt-on accessibility
  • Exclusionary accessibility

Webinar recording, slides and transcript

You can find the slides that were used in the webinar, below. A captioned webinar recording is below, and a transcript will be provided here soon.

For additional information read answers to frequently asked questions about AbilityNet webinars

Useful resources mentioned in the webinar

Follow up questions and answers from the session

Dafydd has responded below to some of the questions that were posed by attendees in the Q&A panel during the webinar.

What is "retrofit" - I have never seen this word

Retrofitting means to add new technology to an older system. With web accessibility, it refers to building a website and then trying add accessibility in afterwards. That is, as opposed to involving accessibility throughout the entire design and development process.

Can ARIA be used for native mobile design?

ARIA can be used for apps if they are using webview. However, for native apps, you need to use the native equivalents.
The same rule that native is better applies. For example, as with a <button> being better than a custom <div>, a UIbutton is better than anything you build from scratch.
However, at least on iOS, there are accessibility traits. These allow you to manually identity the accessibility states, role and properties, of objects.
For a good article on using them, see Delivering an Exceptional Accessibility Experience.
Android development does not offer the same toolkit for very easily improving custom components. It is possible, but much harder. It would require a deep-dive to explain the nuance. So for more I’ll just signpost Make apps more accessible as a great resource.  

If you had a set of instructions with screenshots but the screen shots were described in the body text, do you need alt text? In the body text do you need to explicitly say “the images show…”

Providing critical information through plain text is very important. For example, a great way to make your AV media more accessibility is providing well-written transcripts.
If the images contained nothing that was not explicitly confirmed in the instructional text, then the images could be marked as decorative. This can be done with a null alt attribute.
For example, <img src=”instruction.png” alt=””>
However, be careful users do not miss out on information that is exclusively in the images. Imagine the instructions for building an IKEA bookcase.
The textual instructions might confirm broadly the same information as the pictures. However, there might be some subtly implied information. For example, if an image showed two people holding it up, this would communicate that the step needs two people.
If you are confident that the images do not provide any additional context or guidance, then they are safe to mark as decorative.
Otherwise, provide alt attributes that focus on the excusive visual information. For example:
For example, <img src=”instruction.png” alt=”illustration of step 2 exemplifying that step should be done with two people”>
While slightly off topic, when providing instructions, make sure to use semantic lists.
For more information about the above, see Web Accessibility Tutorials - Images and Web Accessibility Tutorials - Page Structure - Lists.

Is it possible to do all this ie keyboard navigation with a simple website kit - I believe it's called a WISYWIG? I use a template called BT Community Kit - there's no "coding" involved, you just type stuff in.  There's facility for things like alt-text that I always use.

The keyboard navigation demonstrated is controlled by the order in which the interactive elements (buttons, links, form fields, etc.) are located in the DOM.
You can think of this as the behind-the-scene code of your website. Although it can be, it is not something that should be controlled exhaustively by developers.
Any WISYWIG editor will build a DOM based on the layout you design. A good editor will allow keyboard users to navigate through the interactive items in a logical order, in line with your design.
I cannot speak to the strengths and weakness of any one WISYWIG editor, though. I would encourage you to try it yourself. Use Tab and Shift + Tab to navigate forwards and back through interactive elements.
Ask yourself can you access the interactive elements? When you tab onto an element, is it visually highlighted? Are you navigating through the page in a logical order?
If you would like a formal way to test your page, eBay has a good test plan for testing using a keyboard. If you notice any problems, I would raise a ticket with the WISYWIG suppliers.

Do you have a resource you recommend that is good for learning about ARIA?

For a great introduction to ARIA, see Mozilla Developer Network - WAI ARIA Basics. As well, Inclusive Components have some great, easy to read, articles on building components with ARIA.
For something more formal and exhaustive, see the WAI ARIA Practices.

How do we plan for User Research for Accessibility?

We will look to do some sessions on this topic in the near future. You can also contact our support team to find out more about AbilityNet's diverse user testing services.

Date of webinar: 
18 Aug 2020 - 13:00