[0426]Introducing ARIA and accessible forms — A11yTO Development 2/3
Keyboard interactions matter!
A11yTO arranged a session about accessibility development and I’m glad to share the notes I took, though I’m not a developer.
Keyboard Interactions Matter!
For people who are using a screenreader or people having difficulty using a mouse, keyboard tapping is one of the best ways for them to access to the content of the website, so it is extremely important to pay attention to keyboard interactions.
So what do we need to do? The following is what Billy Gregory, co-organizer of A11yTO summarized.
1/Everything that is actionable via mouse is actionable via keyboard
2/Use natively focusable elements whenever possible
3/Understand HOW people navigate using a keyboard
Focus Issues
1/Visible Focus
If I can see it on hover, I better see it on focus. This is the first thing I test.
2/Focus Management
If a user opens something, or is promised something via a control(like a dialog) you better deliver!
3/Focus Control
Making non-native elements focusable.
What is ARIA?
- Web Accessibility initiative — Accessible Rich Internet Applications
- Roles, States and Properties
- A set of attributes used to provide further semantic meaning to the code
- Helps assistive technology users better understand and navigate complex widgets or applications
To know more about ARIA, please visit wikipedia.
Roles, States and Properties
Name: What is the name of the object?
State: What is it doing?
Role: What is it?
Value: May or may not be applicable depending on the object
Billy showed a lot examples on how to use different attributes to tell users what the object is, what do they do, as well as what can they do with those objects. You can find more examples in Practical ARIA Examples here.
Building accessible forms
The next part of the event was about building a form that is accessible for screen readers, presented by Jonny James.
Jonny used a 12-step form building, showing how to make voice over read out the label of the form in a correct way, read out both the questions as well as the answers for radio buttons, as well as error-handling. It was quite technical, so I won’t be able to show you the whole process here, but I was quite impressed by the error-handling they took.
First, there will be error message summary at the top. Users can go through all of them and go to the first error place, or tab one of the error message, jump to the error place, revise it and then go to another one. They added links to next steps between each message, which is very user-friendly.
Jonna also mentioned avoid the use of placeholder text, which you can know more about why form Nielsen Norman Group here.
Though I’m not a developer, I have some basic foundation of HTML, which made it possible for me to understand this workshop. But as a designer, there is still a lot that we can do, such as considering about color contrast, big buttons…These will not only do good to people with disabilities but also the everyone, as the curb-cut effect stated.
