This is a terrific and nuanced talk that packs a lot into less than twenty minutes.
I heartily concur with Rich’s assessment that most websites aren’t apps or documents but something in between. It’s a continuum. And I really like Rich’s proposed approach: transitional web apps.
(The secret sauce in transitional web apps is progressive enhancement.)
On the surface this is about the pros and cons of minting a new HTML search element to replace div role="search" but there’s a deeper point which is that, while ARIA exists to the plug the gaps in HTML, the long-term goal is to have no gaps.
ARIA is not meant to replace HTML. If anything, the need to use ARIA as ‘polyfill’ for HTML semantics could be considered as a sign and a constant reminder of the fact that HTML falls short on some semantics that benefit users of assistive technologies.
This is a fascinating deep dive by Léonie on the inner workings of speech synthesis. She has quite a conundrum: she wants fast playback, but she also wants a voice that doesn’t sound robotic. Unfortunately it’s the robotic-sounding voices that work best at speed.
If you’re interested in this topic, I highly recommend listening to (or reading) the accessibility episode of the Clearleft podcast which featured Léonie as a guest giving demos and explanations.
The annual day-long online accessibility event is back on September 23rd.
No sign-up. No registration. All sessions are streamed live and publicly on the Inclusive Design 24 YouTube channel.
Apparently the sentence forms that I kicked off with Huffduffer are making a comeback.
Businesses focus on efficiencies—doing the things that net them the most money for the least effort. By contrast, taxpayer-funded public programs are designed and expected to cover everyone—including, and especially, the most marginalized. That’s why they’re taxpayer-funded; so they don’t face existential risk be eschewing profit-driven decision-making. Does this work perfectly? No. But I think about it a lot when people shit on the bigness and slowness of government. That bigness & slowness is supposed to create space and resources to account for the communities, that a “lean,” fast approach deliberately ignores.
A great introduction to structuring your content well:
Using semantic HTML as building blocks for a website will give you a lovely accessible foundation upon which to add your fancy CSS and whizzy JavaScript.
Yikes!
We’re updating the way Google Docs renders documents. Over the course of the next several months, we’ll be migrating the underlying technical implementation of Docs from the current HTML-based rendering approach to a canvas-based approach to improve performance and improve consistency in how content appears across different platforms.
I’ll be very interested to see how they handle the accessibility of this move.
This is a great deep dive into a single component, a password toggle in this case. It shows how assumptions are challenged and different circumstances are considered in order to make it truly resilient.
A very comprehensive directory of accessibility resources.
Given the widespread browser support for prefers-reduced-motion now, this approach makes a lot of sense.
A good tutorial on making password fields accessible when you’ve got the option to show and hide the input.
Vitaly has rounded up a whole load of accessibility posts. I think I’ve linked to most of them at some point, but it’s great to have them all gathered together in one place.
I really like the approach that Carie takes here. Instead of pointing to specific patterns to use, she provides a framework for evaluating technology. Solutions come and go but this kind of critical thinking is a long-lasting skill.
Based on the problems with accessiBe and its ilk, I have signed my name to this:
- We will never advocate, recommend, or integrate an overlay which deceptively markets itself as providing automated compliance with laws or standards.
- We will always advocate for the remediation of accessibility issues at the source of the original error.
- We will refuse to stay silent when overlay vendors use deception to market their products.
- More specifically, we hereby advocate for the removal of accessiBe, AudioEye, UserWay, User1st, MK-Sense, and all similar products and encourage the site owners who’ve implemented these products to use more robust, independent, and permanent strategies to making their sites more accessible.
This is a really interesting take on the intersection between accessibility and progressive enhancement (which I always felt was there, but this expresses it well):
Accessibility aims to optimize an experience across a spectrum of user capabilities. Progressive enhancement aims to optimize an experience across a spectrum of user agent capabilities.
Indeed, if you broaden the definition of “user agent” to include a user’s physiology, I think the concepts become nearly identical.
Vasilis offers some research that counters this proposal.
It makes much more sense to start each page with the content people expect on that page. Right? And if you really need navigation (which is terribly overrated if you ask me) you can add it in the footer. Which is the correct place for metadata anyway.
That’s what I’ve done on The Session.
I like this proposal, and I like that it’s polyfillable (which is a perfectly cromulent word).
This is handy—an up-to-date list of tests run on form fields with different combinations of screen readers and browsers.
An excellent collection of advice and examples for making websites responsive and accessibile (responsive + accessible = responsible).