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.
- 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.
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.
Tip 1: use JS to help information as text
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?
- form elements
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.
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.