Skip to content

Accessibility: Don’t turn off your JavaScript just yet! #A11YMTL

Accessibility is not a universal notion. It all depends on where you stand and what your needs are. Aim to be really accessible for some first otherwise you risk becoming barely accessible to all. That’s not an experience you want to give your users. Here’s the link to download the presentation. It is much prettier than my notes.

Assistive technologies

  • screen readers: it’s the first thing we think about when we think about assistive technologies
  • keyboard: yup, you should always consider the keyboard as an assistive technology
  • dragon naturally speaking: this is not a software that was thought for assistive technology but it really works so it’s in the list
  • sip & puff switch: this is more of a breath control type of AT
  • eye tracking
  • and more

Once you’ve made your website accessible for keyboard, most other assistive technologies are covered up to a certain point. People with disabilities are by far the largest minority group on the web. Not everyone who is considered disabled has a disability online. The same goes for some people who may not consider themselves disables…they could be having a very hard time navigating some websites.

Temporary impairments

Accessibility isn’t just for people in wheelchairs. Fall on the snow in a funky manner and you could end up with a temporary impairment that will make you value accessibility.

Avoid stupid decisions

You are not your user. So please, involve real users with disabilities in your testing process. Otherwise you could end up with quite a few engineering fails that meet accessibility standards BUT are just not usable.

JavaScript

We can use JavaScript to increase accessibility in some cases. Stop hanging on to this outdated notion that a website has to be JavaScript free to be accessible. 97% of assistive technologies are JavaScript compliant nowadays.

Tip 1: use JS to help information as text

Don’t be an asshole. When you try to get fancy with design and reassure your user on their journey through a process (with a fancy progress bar for example)…make sure that you do this for ALL of your users by providing information as text via JavaScript.

Tip 2: focus management

Things move from one page to another. When we move content on a page, we need to make sure we need to move the focus as well. We have to make sure that the focus is reachable programmatically or that if links are being activated, there’s a visual hint to that effect.

What are the focusable elements?

  • links
  • buttons
  • form elements
  • iframe
  • etc.

There’s a huge list available on allyjs.io/data-tables/focusable.html.
But you can also focus on non-focusable elements with tabindex=”0″ and tabindex=”1″. This will allow you to let users to put focus on the elements using tabindex=”0″. Modal windows can be handled with tabindex=”1″.

Accessible modal window

The problem with modal windows is that they don’t appear in a normal tab order. It captures the keyboard until the window is closed and it sets focus on the heading. You should be able to close modals with the “esc” or the close button.

Focus on purpose, not mechanics of action

It’s OK to get from point A to point B by using different routes. Who cares? Just make sure that when you make something accessible, it can be used with a keyboard, a mouse, a voice application, etc.

Modify the default behavior

Stop reinventing the wheel! We as humans have a tendency to rely on some well-established conventions. When you change default behavior for some buttons or links (or anything else really), it can cause mayhem for some users that navigate your website in a manner that isn’t the way you expected them to.

Making an accessible tool tip for keyboard navigation is quite difficult.

Dynamic content

Make sure that the content generated dynamically is accessible. Can you trigger content with a keyboard for example? When the content refreshes quite quickly, you need to be careful with the rate of refresh and how you refresh the content.

Dynamic content can be generated automatically or can be generated following a user action.

WAI ARIA fight club rule: when you can get away with not using WAI ARIA, DO IT!

Leverage ARIA roles, properties and states to help assistive technologies. Death to the meaningless red asterix! Let’s use something that has meaning instead!

Accessibility and Google rendering go hand in hand.

If you have issues accessing your content via a crawler, chances are assistive technologies are going to have a hard time.

For Angular: ng-aria can be useful for accessibility. 

Comments are closed.