A first approach of ARIA with a toggle button
Courses that somehow seems relevant to every web developer. There is a 10-day trial.
So the question is, when you have done everything "right" in your attempt to do the right thing and it still doesn't work, at what point do you give up and when do you push on and try to make it right?
What to do?
- Do nothing (and it degrades user experience for years until a fix is made)
- Suggest an alternative (and it takes years to fix to go through the roadmap)
- Work around it
- Engineer a solution
Use accessibility APIs of OSes that contains building blocks. These building blocks have 3 kinds of information about a UI element.
The first is a role: What kind of element is this?
The second is a name: a label or an identifier for this element.
The third is state and other properties: Other functional aspects of an element that would be relevant for a user or an assistive technology to be aware of. Is a checkbox checked or unchecked, etc...
It looks like ARIA, oh wait!
The web browsers now expose this accessibility tree.
In a form, the user gets the screen reader navigation capabilities. The tab key becomes the norm again, and all that helps without aria is then the <label for="">
each input.
aria-label, aria-labelledby, and aria-describedby can all be used to bring extra clarity to a given element when it's exposed to assistive technology.
- aria-label overrides an element's name with contents you specify.
- aria-labelledby replaces an element's name with contents from another node on the page. You'd use this when you'd already have a visible label anyways.
- aria-describedby sets your element's description to the contents of another node on the page. This is great for noncritical, supplemental information.
- aria-description… is coming.
As always, avoid ARIA whenever possible.
Using a description list dl
with description terms dt
and their description detail dd
: so basically a list of key - value pairs.
Advangtages for screen readers instead of divs:
- The screenreader could tell the user how many name–value groups are in the list.
- The screenreader could tell the user how far into the list they are.
- he screenreader could treat the list as one block that the user could skip over if they're uninterested in it.
In the meantime:
.visually-hidden:not(:focus):not(:active) {
border: 0;
clip: rect(0 0 0 0);
clip-path: inset(50%);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
white-space: nowrap;
width: 1px;
}
It is when you start to not be fully able that
Through all of it, I’ve found myself noticing “accessibility” helpers more than ever before: that railing on the stairs, that ramp off to the side of the building, that elevator tucked away in the back.
1 in 5 people currently have a disability. 100% of people will have some form of disability in their lifetime.
To annotate accessibility features on mockups. Discovered from https://adhoc.team/2023/06/28/become-an-accessibility-champion-by-using-simple-mockup-annotations/
An argument in favor of emoji instead of raw ASCII ones:
There are a lot of blind people on here, who use screen reader software to tell them what is on the screen. To help screen reader users, it's a good idea to use emoji rather than old-style smileys.
For example 😄 will be read out loud as "smile" because that's its alt text. However, :D will be read out loud as "colon D".
It's a growing directory of tools, articles, books, podcasts, and other learning resources to guide us in creating more ethical and more inclusive products.
To favorise:
- checkbox
- file
- hidden
- radio
- password
- text
To avoid:
- button
- date
- datetime-local
- month
- number
- reset
- search
- submit
- time
- week
The rest is not sure or evident...
If a state is important enough to indicate visually, it's probably important enough to expose to assistive technologies.
With an example such as <a href="/about" aria-current="page" class="current-page">
, we now have two meanings that convey the same information: the aria attribute and the class. This can leads to bugs while refactoring.
Another example is provided with dropdowns or toggle buttons, and sorted table columns.
Mentions to :disabled or aria-disabled, :invalid or aria-invalid, aria-selected, role="tab", and the list can go on!
You need to be using the appropriate elements (s are your friend!), and managing the appropriate attributes and their values to make truly accessible user experiences.