Ethan ponders what the web might be like if the kind of legal sticks that exist for accessibility in some countries also existed for performance.
Bruce reveals that the theory and the reality are somewhat different when it comes to the accessibility of inline elements like
I recently asked a friend who happens to be blind if he’d share some sites that were built really well—sites that were beautifully accessible. You know what he said? “I don’t use the web. Everything is broken.”
Everything is broken. And it’s broken because we broke it.
But we can do better.
It’ll never catch on.
“What if someone doesn’t browse the web like I do?”
The long-standing difficulties of styling
legend are finally getting addressed …although I’m a little shocked that the solution involves extending
-webkit-appearance. I think that, at this point, we should be trying to get rid of vendor prefixes from the web once and for all, not adding to them. Still, needs must, I suppose.
This is very timely. I’ve been doing some consulting at a company where they are perhaps a little over-reliant on automated accessibility tests.
Automated accessibility tests are a great resource to have, but they can’t automatically make your site accessible. Use them as one step of a larger testing process.
I love this deep dive that Sara takes into the question of marking up content for progressive disclosure. It reminds me Dan’s SimpleQuiz from back in the day.
Then there’s this gem, which I think is a terrificly succinct explanation of the importance of meaningful markup:
It’s always necessary, in my opinion, to consider what content would render and look like in foreign environments, or in environments that are not controlled by our own styles and scripts. Writing semantic HTML is the first step in achieving truly resilient Web sites and applications.
Just last week I came across an example of what Ethan describes here: accessibility (in a pattern library) left to automatic checks rather than human experience.
A great post by Tim following on from the post by Eric I linked to last week.
Is a secure site you can’t access better than an insecure one you can?
He rightly points out that security without performance is exlusionary.
…we’ve made a move to increase the security of the web by doing everything we can to get everything running over HTTPS. It’s undeniably a vital move to make. However this combination—poor performance but good security—now ends up making the web inaccessible to many.
Security. Performance. Accessibility. All three matter.
This is a heartbreaking observation by Eric. He’s not anti-HTTPS by any stretch, but he is pointing out that caching servers become a thing of the past on a more secure web.
Can we do anything? For users of up-to-date browsers, yes: service workers create a “good” man in the middle that sidesteps the HTTPS problem, so far as I understand. So if you’re serving content over HTTPS, creating a service worker should be one of your top priorities right now, even if it’s just to do straightforward local caching and nothing fancier.
Inclusive design is also future-proofing technology for everyone. Swan noted that many more developers and designers are considering accessibility issues as they age and encounter poor eyesight or other impairments.
Oh, this is magnificent! A rallying call for everyone designing and developing on the web to avoid making any assumptions about the people we’re building for:
People will use your site how they want, and according to their means. That is wonderful, and why the Web was built.
I would even say that the % of people viewing your site the way you do rapidly approaches zilch.
A handy bunch of checklists from Dave for creating accessible components. Each component gets a card that lists the expectations for interaction.
I encourage you to think about and make sure you are using the right elements at the right time. Sometimes I overthink this, but that’s because it’s that important to me - I want to make sure that the markup I use helps people understand the content, and doesn’t hinder them.
A great collection of styled and accessible form elements:
Form controls are necessary in many interfaces, but are often considered annoying, if not downright difficult, to style. Many of the markup patterns presented here can serve as a baseline for building more attractive form controls without having to exclude users who may rely on assistive technology to get things done.
The slides and video from a really great well-rounded talk by Aaron, filled with practical examples illustrating concepts like progressive enhancement and inclusive design.
Sara shows a few different approaches to building accessible toggle switches:
Always, always start thinking about the markup and accessibility when building components, regardless of how small or simple they seem.
Léonie makes a really good point here: if you’re adding