Tags: a11y

141

sparkline

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.

Accessibility: Start with the foundations | susan jean robertson

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.

The Accessibility of Styled Form Controls & Friends | a11y_styled_form_controls

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.

Designing for Everyone: Building Great Web Experiences for Any Device

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.

On Designing and Building Toggle Switches

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.

Short note on progressive ARIA by The Paciello Group

Léonie makes a really good point here: if you’re adding aria attributes to indicate interactions you’re making available through JavaScript, then make sure you also use JavaScript to add those aria attributes.

Accessibility for Teams

I really, really like the way that this straightforward accessibility guide is subdivided by discipline. As Maya wrote in the blog post announcing its launch:

Each person on a team, whether you’re a manager, designer, or developer, has a role to play. Your responsibilities are different depending on your role. So that’s how we structured the guide, with a separate section for each of five roles:

  • Product management
  • Content design
  • UX design
  • Visual design
  • Front-end development

Pixels vs. Ems: Users DO Change Font Size – Evan Minto – Medium

I have to admit, I didn’t realise that text reszing behaved differently for user preferences compared to page zoom. For that reason alone, I’m going to avoid setting font sizes in pixels.

If 2 to 3% (or more!) of your users are relying on a custom font size, you should know that so you can either support that user preference or make a conscious decision to not support it. Doing anything less is frankly irresponsible, especially considering that users with larger font sizes may be using those sizes to compensate for visual disabilities.

Don’t Use The Placeholder Attribute — Smashing Magazine

A lot of the issues here are with abuses of the placeholder attribute—using it as a label, using it for additional information, etc.—whereas using it quite literally as a placeholder can be thought of as an enhancement (I almost always preface mine with “e.g.”).

Still, there’s no getting around that terrible colour contrast issue: if the contrast were greater, it would look too much like an actual pre-filled value, and that’s potentially worse.

Artificial Intelligence for more human interfaces | Christian Heilmann

An even-handed assessment of the benefits and dangers of machine learning.

Know your ARIA: ‘Hidden’ vs ‘None’ | scottohara.me

When to use aria-hidden="true", and when you might need display: none:

aria-hidden by itself is not enough to completely hide an element from all users, if that is the end goal.

When to use role="presentation" (or role="none"):

Where aria-hidden can be used to completely hide content from assistive technology, modifying an element’s role to “none” or “presentation” removes the semantics of the element, but does not hide the content from assistive technologies.

The Tarot Cards Of Tech

A useful set of questions to ask on any project, shuffled and dealt to you.

They’ll not only help you foresee unintended consequences—they can also reveal opportunities for positive change.

All of the content in images. Not a single image has alternative text. If only they had asked themselves:

When you picture your user base, who is excluded? If they used your product, what would their experience be like?