Tags: a11y

152

sparkline

The power of progressive enhancement

Andy’s slides:

We dive into why progressive enhancement is important and how we can leverage the power of Vanilla JavaScript, Web Components and modern CSS to deliver a hack-free, lightweight and progressive experience for our users.

as days pass by — Why isn’t it their job

The secret is: if you use semantic HTML, then they do the work, not you. Their browser does the work, not you. If your pages use semantic HTML, you’re not going to get bug reports saying that your web app doesn’t work in a screenreader, or your buttons don’t work without mouse clicks, or your site doesn’t show anything on a Yoyodyne SuperPhone 3 running FailBrowser, because it will and they will and it will. And using semantic HTML elements is no more effort; it’s just as easy to use main as it is to use div id="main". Easier, even.

ANDI - Accessibility Testing Tool - Install

Another bookmarklet for checking accessibility—kind of like tota11y—that allows to preview how screen readers will handle images, focusable elements, and more.

Using aria-live

A terrific explanation of the aria-live attribute from Ire. If you’re doing anything with Ajax, this is vital knowledge.

Drupal’s commitment to accessibility | Dries Buytaert

Shots fired!

I’ve come to believe that accessibility is not something you do for a small group of people. Accessibility is about promoting inclusion. When the product you use daily is accessible, it means that we all get to work with a greater number and a greater variety of colleagues. Accessibility benefits everyone.

Designing, laws, and attitudes. — Ethan Marcotte

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 Lawson’s personal site  : Screenreader support for text-level semantics

Bruce reveals that the theory and the reality are somewhat different when it comes to the accessibility of inline elements like em and strong.

Website Accessibility Begins with Responsive Web Design

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.

My favorite design tool. — Ethan Marcotte

“What if someone doesn’t browse the web like I do?”

The State of Fieldset Interoperability - Bocoup

The long-standing difficulties of styling fieldset and 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.

The Importance Of Manual Accessibility Testing — Smashing Magazine

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.

How do you mark up an accordion? — Sara Soueidan

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.

Accessibility is not a feature. — Ethan Marcotte

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.

On HTTPS and Hard Questions - TimKadlec.com

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.

Accessible Comics - Axess Lab

Nice! It sounds like Lucy and Andy went above and beyond the call of duty when it came to the alt text for 100 Demon Dialogues.

Securing Web Sites Made Them Less Accessible – Eric’s Archived Thoughts

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.

‘Never assume anything’: The golden rules for inclusive design

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.

The Web is Made of Edge Cases by Taylor Hunt on CodePen

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.

Nutrition Cards for Accessible Components A11Y Expectations

A handy bunch of checklists from Dave for creating accessible components. Each component gets a card that lists the expectations for interaction.