The 5 Rules of ARIA

Directly from the spec, the 5 Rules of ARIA:

  1. If you can use a native HTML element or attribute with the semantics and behavior you require already built in […] then do so.
  2. Do not change native semantics, unless you really have to.
  3. All interactive ARIA controls must be usable with the keyboard.
  4. Do not use role="presentation" or aria-hidden="true" on a focusable element .
  5. All interactive elements must have an accessible name.

That first rule is like music to my ears … embrace the platform, folks!

Accessibility in Design Systems

Good slidedeck by Benno Lœwenberg:

We all are only sometimes abled. Therefore accessible solutions benefit everybody. Treating accessibility not just as an afterthought to comply with regulations, but as an essential UX factor right from the start can lead to building better products and services.

This talk is about how to lay an accessible foundation within a design system to enable accessibility. It also covers what to start with, which aspects to take care of and the toolbox needed, using tangible examples (and cool graphics) to generate an instant understanding.

Accessibility in Design Systems →

There’s something ironic about these slides being hosted on SlideDeck though, as doing so makes them inaccessible …

Thankfully there’s a way to download the original slides (PDF)

Accessible front-end components: claims vs reality

Great post by Hidde, warning about blindly trusting accessibility claims.

Not all ‘accessible components’ are created equal, some will work a lot better for our end users than other. In this post I have listed a number of things you can look at if you are considering third-party components.

I especially like this part:

Sometimes, HTML-only patterns are easier to understand for end users. More ARIA does not mean more accessibility.

It overlaps perfectly with Jeremy‘s thoughts in Robustness and Least Power

Accessible front-end components: claims vs reality →

W3C WAI Curricula on Web Accessibility

Over at the W3C Web Accessibility Initiative (WAI) website you can find an extensive curricula on Web Accessibility

This resource provides teaching modules to help you create courses on digital accessibility, or to include accessibility in other courses. The modules cover accessibility foundations that apply broadly, and specific skills for developers, designers, content authors, and others.

Wow, these surely would’ve come in handy back when I was a lecturer Web & Mobile 😅

Curricula on Web Accessibility: A Framework to Build Your Own Courses →

Writing Good Alt Text

Jake and Surma tackle the age-old problem: what should you include in an image’s alt text?

Responsible Web Applications

Good little collection of tips for creating responsible (= responsive + accessible) web applications by Joy Heron.

With modern HTML and CSS, we can create responsive and accessible web apps with relative ease. In my years of doing software development, I have learned some HTML and CSS tips and tricks, and I want to present these in this post. This list is not exhaustive, but these are tried and true patterns that I frequently use in different projects.

A shame she calls them “tips and tricks though, as there for example is no “trick” to using proper headings and landmarks — It is a basic idea/pattern every frontend dev should know about and apply, no magic needed.

Responsible Web Applications →

Sidenote: You might want to refrain from using the <details> as an accordion though …

Alt vs Figcaption

This message by Elaina Natario writing over at Thoughtbot cannot be repeated enough:

While both the alt attribute and the figcaption element provide a way to describe images, the way we write for them is different. alt descriptions should be functional; figcaption descriptions should be editorial or illustrative.

Examples of both functional and editorial descriptions in the full post!

Alt vs Figcaption →