My mission in web accessibility is to make it easier for people who want to create accessible interfaces. There are many means to that end, from building good understanding of how people with disabilities use the web to providing clear and well-tested code examples.

I mean, if you understand how people use the web with a mouse, it is easier to design a mouse cursor that works for them, or write the code to implement one. This also applies to keyboard, switch controls, voice navigation, touch and screenreaders.

I like the power of reusable components, as they allow for baking accessibility into components, whether in frameworks or vanilla. One day there may be better UI controls in the web platform and/or more accessible defaults in browsers. Now, teams often build their own components (see Smashing’s guide for tips). Of course, not all project teams can always build their own components every single time. This is not ‘Nam, there are deadlines. And so, we commonly use third-party components like custom selects, autocompletes and date pickers.

In this post, I will warn you about blindly trusting accessibility claims and share some questions to ask with each third party component you consider for your project.

“Accessible” doesn’t say it all

As accessibility-aware developers, we may look specifically for components that are accessible. Maybe we search the web for ‘accessible X’. If you do that, be aware that there are more components that claim to be accessible than components that actually are usable or great to use for people with disabilities.

Sometimes, ‘accessible’ means only partially accessible. That’s a problem, as accessibility is about making interfaces work for people with a broad range of disabilities (see Diverse abilities and barriers). For instance, what to think of a widget that was made to work with a keyboard, but breaks badly when zoomed in? It has perfect colour contrast, but no HTML semantics? The screenreader experience is excellent, but it is tricky for users who control their system with voice?

Sometimes, ‘accessible’ means ‘has a bunch of ARIA attributes’. In the best case ‘has ARIA attributes and keyboard behaviours that exactly meet the ARIA standard’. Sometimes that it is a 1:1 implementation of the ARIA Authoring Practices Guide (APG), a set of examples (not a standard) written by a subgroup of the ARIA Working Group. The APG is an excellent resource if you want to know how to write technically correct ARIA. But… it does not make claims about screenreader compatibility, see ARIA-AT and/or a11ysupport for that. It also does not make claims about user experience, so always be sure to test the patterns with people, or read blog posts from others who tested with people. Lastly, it also does not recommend whether to use ARIA or go HTML-only… it is just about using ARIA. Sometimes, HTML-only patterns are easier to understand for end users. More ARIA does not mean more accessibility.

Sorry, I realise none of this makes it particularly easy to find accessible components, but I want to be honest. In any case: don’t give up. Remember what Léonie Watson once said about accessibility: “it doesn’t have to be perfect, it just has to be a little bit better than yesterday”. The more research we do, the better informed our choice will be.

Some questions to ask

If we want to have a little more certainty about the accessibility of a component, there are some checks we can do.

How did they test?

It’s good news when a component’s website explains how a component was tested. Usually browser support is listed, sometimes support for assistive technologies like screenreaders is included, too. Maybe they’ve done formal WCAG testing or they have some sort of checklist. They may be running only automated tests, which are good and useful, but limited to things that can be automatically tested (most of WCAG cannot be). Information about the type(s) of testing can help inform us about the accessibility of a component.

Who did they test with?

Testing accessibility is ultimately not about technology, though, it is about making sure the pattern works for people with disabilities. If we look at a component, can we find whether they specifically included people with disabilities? Was a broad range of disabilities included?

Representation matters; accessibility often requires testing a broad range of people, disabilities and assistive devices. When Marcy Sutton user tested patterns for accessible routing, users of screenreaders, voice navigation and switch controls had varied experiences and comments (see What we learned from user testing accessible client-side routing).

Are they open about pros and cons of their approach?

Accessibility is not always one size fits all, sometimes there may be caveats to an approach, there may be things that may still be experimental. It’s a good sign if the component developer is open about this. Sometimes there will be an accessibility statement with known issues and planned fixes.

Who created them?

Sometimes I put extra trust if the people or organisations that created components work for the public good and/or in accessibility. Government-backed component libraries like the gov.uk design system, the New Zealand government design system and the US government’s design system contain gems. So do pattern libraries created by accessibility practitioners like Deque’s Cauldron and Tenon UI.

More indicators

I also asked around on social media! Below are some of the tips that were shared there (❤️ thanks all!)

Look at GitHub issues

Marcus recommended to look at GitHub issues about WCAG or accessibility, “their presence would be a warning sign”. Thea said it can also be a “sign that people care”, she suggests looking at activity and discussions on issues. Mitchell agreed: “the quest for optimal usability and interoperability is never done”. Mallory +1’ed too and looks at how authors respond.

Accessibility as an integral part

Sara warned to be wary of treating accessibility as a separate feature rather than an integral part of the work. If there is an accessible version and a non-accessible version, they’ve probably failed that test!

Find specifics

Bogdan would look for specifics of the accessibility claim: which version and level of WCAG are we talking? He and Weston also said to look for which specific screenreaders were tested.

Perform basic checks

Various people said basic checks can give away a lot: do the docs even mention accessibility (Oscar), is there sufficient colour contrast (Martin), does it work with just a keyboard (Brent and Eric)?

Find out about committment

Heather recommended to look at the website of the component; obvious accessibility issues there say something about the claimed commitment to accessibility.

Yakim said we should look at the testing method to gauge how sustainable accessibility efforts are: “are they ongoing and proactive, or are they reactive?”

In his blog post Be wary of accessibility guarantees of accessibility vendors, which is more about accessibility of tools in general, Adrian recommends going on Twitter and searching the company name combined with the #a11y hashtag.

Customisability

If nothing is perfect, why not improve one of the most promising candidates? Martin mentioned licensing: with a permissive license, we could fix any accessibility barriers ourselves. He and Jason mentioned this too: if the component has easy to use APIs and hooks for customisability, we can take matters into our own hands..

Wrapping up

To sum up: 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.

---

Reply via email

My mission in web accessibility is to make it easier for people who want to create accessible interfaces. There are many means to that end, from building good understanding of how people with disabilities use the web to providing clear and well-tested code examples.

I mean, if you understand how people use the web with a mouse, it is easier to design a mouse cursor that works for them, or write the code to implement one. This also applies to keyboard, switch controls, voice navigation, touch and screenreaders.

I like the power of reusable components, as they allow for baking accessibility into components, whether in frameworks or vanilla. One day there may be better UI controls in the web platform and/or more accessible defaults in browsers. Now, teams often build their own components (see Smashing’s guide for tips). Of course, not all project teams can always build their own components every single time. This is not ‘Nam, there are deadlines. And so, we commonly use third-party components like custom selects, autocompletes and date pickers.

In this post, I will warn you about blindly trusting accessibility claims and share some questions to ask with each third party component you consider for your project.

“Accessible” doesn’t say it all

As accessibility-aware developers, we may look specifically for components that are accessible. Maybe we search the web for ‘accessible X’. If you do that, be aware that there are more components that claim to be accessible than components that actually are usable or great to use for people with disabilities.

Sometimes, ‘accessible’ means only partially accessible. That’s a problem, as accessibility is about making interfaces work for people with a broad range of disabilities (see Diverse abilities and barriers). For instance, what to think of a widget that was made to work with a keyboard, but breaks badly when zoomed in? It has perfect colour contrast, but no HTML semantics? The screenreader experience is excellent, but it is tricky for users who control their system with voice?

Sometimes, ‘accessible’ means ‘has a bunch of ARIA attributes’. In the best case ‘has ARIA attributes and keyboard behaviours that exactly meet the ARIA standard’. Sometimes that it is a 1:1 implementation of the ARIA Authoring Practices Guide (APG), a set of examples (not a standard) written by a subgroup of the ARIA Working Group. The APG is an excellent resource if you want to know how to write technically correct ARIA. But… it does not make claims about screenreader compatibility, see ARIA-AT and/or a11ysupport for that. It also does not make claims about user experience, so always be sure to test the patterns with people, or read blog posts from others who tested with people. Lastly, it also does not recommend whether to use ARIA or go HTML-only… it is just about using ARIA. Sometimes, HTML-only patterns are easier to understand for end users. More ARIA does not mean more accessibility.

Sorry, I realise none of this makes it particularly easy to find accessible components, but I want to be honest. In any case: don’t give up. Remember what Léonie Watson once said about accessibility: “it doesn’t have to be perfect, it just has to be a little bit better than yesterday”. The more research we do, the better informed our choice will be.

Some questions to ask

If we want to have a little more certainty about the accessibility of a component, there are some checks we can do.

How did they test?

It’s good news when a component’s website explains how a component was tested. Usually browser support is listed, sometimes support for assistive technologies like screenreaders is included, too. Maybe they’ve done formal WCAG testing or they have some sort of checklist. They may be running only automated tests, which are good and useful, but limited to things that can be automatically tested (most of WCAG cannot be). Information about the type(s) of testing can help inform us about the accessibility of a component.

Who did they test with?

Testing accessibility is ultimately not about technology, though, it is about making sure the pattern works for people with disabilities. If we look at a component, can we find whether they specifically included people with disabilities? Was a broad range of disabilities included?

Representation matters; accessibility often requires testing a broad range of people, disabilities and assistive devices. When Marcy Sutton user tested patterns for accessible routing, users of screenreaders, voice navigation and switch controls had varied experiences and comments (see What we learned from user testing accessible client-side routing).

Are they open about pros and cons of their approach?

Accessibility is not always one size fits all, sometimes there may be caveats to an approach, there may be things that may still be experimental. It’s a good sign if the component developer is open about this. Sometimes there will be an accessibility statement with known issues and planned fixes.

Who created them?

Sometimes I put extra trust if the people or organisations that created components work for the public good and/or in accessibility. Government-backed component libraries like the gov.uk design system, the New Zealand government design system and the US government’s design system contain gems. So do pattern libraries created by accessibility practitioners like Deque’s Cauldron and Tenon UI.

More indicators

I also asked around on social media! Below are some of the tips that were shared there (❤️ thanks all!)

Look at GitHub issues

Marcus recommended to look at GitHub issues about WCAG or accessibility, “their presence would be a warning sign”. Thea said it can also be a “sign that people care”, she suggests looking at activity and discussions on issues. Mitchell agreed: “the quest for optimal usability and interoperability is never done”. Mallory +1’ed too and looks at how authors respond.

Accessibility as an integral part

Sara warned to be wary of treating accessibility as a separate feature rather than an integral part of the work. If there is an accessible version and a non-accessible version, they’ve probably failed that test!

Find specifics

Bogdan would look for specifics of the accessibility claim: which version and level of WCAG are we talking? He and Weston also said to look for which specific screenreaders were tested.

Perform basic checks

Various people said basic checks can give away a lot: do the docs even mention accessibility (Oscar), is there sufficient colour contrast (Martin), does it work with just a keyboard (Brent and Eric)?

Find out about committment

Heather recommended to look at the website of the component; obvious accessibility issues there say something about the claimed commitment to accessibility.

Yakim said we should look at the testing method to gauge how sustainable accessibility efforts are: “are they ongoing and proactive, or are they reactive?”

In his blog post Be wary of accessibility guarantees of accessibility vendors, which is more about accessibility of tools in general, Adrian recommends going on Twitter and searching the company name combined with the #a11y hashtag.

Customisability

If nothing is perfect, why not improve one of the most promising candidates? Martin mentioned licensing: with a permissive license, we could fix any accessibility barriers ourselves. He and Jason mentioned this too: if the component has easy to use APIs and hooks for customisability, we can take matters into our own hands..

Wrapping up

To sum up: 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.

---

Originally posted as Accessible front-end components: claims vs reality on Hidde's blog.

Reply via email

In recent weeks, people have been publishing “typical day” posts. They have been fun to read. In what Ethan Marcotte aptly called a “blogging chain”, started by Colin Devroe, Michelle tagged me and some others. So, here it goes, some typical things about my daily life.

I’ve been admiring other people’s ability to wake up early, go for early-morning runs and/or have carefully carved out daily schedules. If you want to read what other people’s days look like, I liked those of Michelle, Matthias, Ethan , Cassie, Jeremy and Sara.

Days have been very different in the last six weeks, as I’ve taken most days off during the Dutch daycare lockdown. Those days were full of cooking together with the kids, long walks with the kids and, when it rained, painting loo rolls (again, with the kids). Super challenging, because how do you balance all that and a freelance business? Working with a baby on one arm and a toddler running around the room is a myth. It was also super rewarding, for all the obvious reasons: babies and toddlers can be immensely cute and lovely. We learn a lot from and about each other.

Below, you’ll find a description of a somewhat regular day. The times and activities can vary.

07.00-8.30

A combination of wake up, make breakfast and coffee. We get everyone dressed, read the morning paper. I read my morning paper physically. This was initially so that I could skip online news, but who am I kidding–even with most news sites blocked via my /etc/hosts, I can’t resist and go peek on my phone.

08.30-9.30

Walk kids to daycare. If I’m alone, this is usually my chance to listen to audiobooks or podcasts on the way back home, and take a longer route if time allows. Podcast-wise, I’m a sucker for long form interviews, like NTR Kunststof, Nooit meer slapen and Groenteman in de kast in Dutch, and James O’Brien’s Full Disclosure and Brené Brown’s Unlocking us in English.

09.30-13.30

This is where I try to get a lot of work done. I usually don’t have meetings, as my US counterparts are still asleep. I may be working on an accessibility audit or presentation slides, or, if it’s a W3C day, I may be coding accessibility conformance tooling, review surveys from the Education & Outreach Working Group or generate the WCAG XSLT over and over for our current redesign project. Usually I drink Taiwanese high mountain tea.

13.30-14.00

Lunch time! I extend it sometimes, especially if I have evening meetings, so that I can go outside and/or cook hot lunch.

14.00-17.00

This is usually a combination of meetings, 1:1s and getting work done. I may be doing some work on components for the WAI website, talk to CMS vendors for WAI-Guide or attempt to split up large amounts of work into GitHub issues. Some time into the global pandemic, I purchased a second hand hifi set and placed it inside my home office, so that I can listen to all the jazz, ambient, pop, rock and hiphop when not in meetings. I check the number of positive COVID tests, which is easier if it decreases.

17.00-19.30

Daycare pick up, cooking and eating. Depending on how smooth things went and how much time there still is, we also use food delivery. I get better at not feeling too guilty about that. After dinner we usually put on music and dance a bit. Sting and Shaggy, Chika, Gregory Porter, Nile Rodgers and Moby have been recent favourites. K3 and their song about washing hands and Juf Roos, too.

19.30-21.00

Trying to get the kids to sleep, read bed time stories, answer mesmerising questions about the universe and its workings. Also wash up and prepare baby food. Sometimes I have an evening meeting. On Thursdays I recently started attending Open UI telecons.

21.00-23.00

Oh, is it this late already? We may watch Mock the Week if there are new episodes, see how Ku explores Taiwan or how Waes visits Japan. Travel and food themed shows help remind there was a prepandemic world. They give me hope that some of it may come back. Sometimes there’s a book I can’t stop reading or a guest in one of the late night talk shows that I don’t want to miss. I go to bed with a book.

Wrapping up

So, this is what my days roughly look like. I don’t really have any useful productivity hacks, but feel that walking, reading, listening, cooking and (even) cleaning are some things that I’m pleased to have in my days.

I’d like to invite Zell Liew, Ana Rodrigues and Eric Bailey to join this chain to talk about their days, if they want to!

---

Reply via email

In recent weeks, people have been publishing “typical day” posts. They have been fun to read. In what Ethan Marcotte aptly called a “blogging chain”, started by Colin Devroe, Michelle tagged me and some others. So, here it goes, some typical things about my daily life.

I’ve been admiring other people’s ability to wake up early, go for early-morning runs and/or have carefully carved out daily schedules. If you want to read what other people’s days look like, I liked those of Michelle, Matthias, Ethan , Cassie, Jeremy and Sara.

Days have been very different in the last six weeks, as I’ve taken most days off during the Dutch daycare lockdown. Those days were full of cooking together with the kids, long walks with the kids and, when it rained, painting loo rolls (again, with the kids). Super challenging, because how do you balance all that and a freelance business? Working with a baby on one arm and a toddler running around the room is a myth. It was also super rewarding, for all the obvious reasons: babies and toddlers can be immensely cute and lovely. We learn a lot from and about each other.

Below, you’ll find a description of a somewhat regular day. The times and activities can vary.

07.00-8.30

A combination of wake up, make breakfast and coffee. We get everyone dressed, read the morning paper. I read my morning paper physically. This was initially so that I could skip online news, but who am I kidding–even with most news sites blocked via my /etc/hosts, I can’t resist and go peek on my phone.

08.30-9.30

Walk kids to daycare. If I’m alone, this is usually my chance to listen to audiobooks or podcasts on the way back home, and take a longer route if time allows. Podcast-wise, I’m a sucker for long form interviews, like NTR Kunststof, Nooit meer slapen and Groenteman in de kast in Dutch, and James O’Brien’s Full Disclosure and Brené Brown’s Unlocking us in English.

09.30-13.30

This is where I try to get a lot of work done. I usually don’t have meetings, as my US counterparts are still asleep. I may be working on an accessibility audit or presentation slides, or, if it’s a W3C day, I may be coding accessibility conformance tooling, review surveys from the Education & Outreach Working Group or generate the WCAG XSLT over and over for our current redesign project. Usually I drink Taiwanese high mountain tea.

13.30-14.00

Lunch time! I extend it sometimes, especially if I have evening meetings, so that I can go outside and/or cook hot lunch.

14.00-17.00

This is usually a combination of meetings, 1:1s and getting work done. I may be doing some work on components for the WAI website, talk to CMS vendors for WAI-Guide or attempt to split up large amounts of work into GitHub issues. Some time into the global pandemic, I purchased a second hand hifi set and placed it inside my home office, so that I can listen to all the jazz, ambient, pop, rock and hiphop when not in meetings. I check the number of positive COVID tests, which is easier if it decreases.

17.00-19.30

Daycare pick up, cooking and eating. Depending on how smooth things went and how much time there still is, we also use food delivery. I get better at not feeling too guilty about that. After dinner we usually put on music and dance a bit. Sting and Shaggy, Chika, Gregory Porter, Nile Rodgers and Moby have been recent favourites. K3 and their song about washing hands and Juf Roos, too.

19.30-21.00

Trying to get the kids to sleep, read bed time stories, answer mesmerising questions about the universe and its workings. Also wash up and prepare baby food. Sometimes I have an evening meeting. On Thursdays I recently started attending Open UI telecons.

21.00-23.00

Oh, is it this late already? We may watch Mock the Week if there are new episodes, see how Ku explores Taiwan or how Waes visits Japan. Travel and food themed shows help remind there was a prepandemic world. They give me hope that some of it may come back. Sometimes there’s a book I can’t stop reading or a guest in one of the late night talk shows that I don’t want to miss. I go to bed with a book.

Wrapping up

So, this is what my days roughly look like. I don’t really have any useful productivity hacks, but feel that walking, reading, listening, cooking and (even) cleaning are some things that I’m pleased to have in my days.

I’d like to invite Zell Liew, Ana Rodrigues and Eric Bailey to join this chain to talk about their days, if they want to!

---

Originally posted as My typical day on Hidde's blog.

Reply via email

Web accessibility becomes easier and cheaper, when you address it earlier. In this post, we’ll look at various ways to do that, like picking the right CMS and making accessibility part of the agile process. Combine them for maximum effect.

A quick disclaimer before we start: while this post is about web accessibility, the same probably goes for web security, web privacy and other important aspects of a healthy web.

To make websites accessible, most organisations choose to follow the Web Content Accessibility Guidelines (WCAG). It’s also the standard most governments embed in their rules. Meeting WCAG does not guarantee accessibility, but the standard is a good baseline. It is our best bet as a shared understanding ‌of what ‘this is accessible’ means.

Choose a CMS that helps with accessibility

WCAG is about the accessibility of content, so it makes sense to optimise what we do when we create content. We could pick CMSes that help editors create accessible content. In my talk “Your CMS is an accessibility assistant”, that I did last year, I discuss just that.

What if a CMS, when you add a video, prompts for subtitles? What if it, when you place text on a hero image, it helps you pick a color that has sufficient contrast, or suggests to add a background color? Some CMSes already ship with features like this.

WordPress’s Gutenberg editor, for instance, will tell you when you’re starting to use colours with insufficient contrast:

Features like this are super helpful, because they let us spot accessibility issues early in the process. Without them, we may have only found out about problems once the functionality went live and got audited. With good early warning systems, WCAG audits can focus on the more complex issues.

Check accessibility with every user story

A lot of web projects rely on some form of agile project management, many move new functionality through a set of stages. If you can build accessibility steps into the process, somewhere before the last stage, you can find and fix accessibility problems before they go live.

There are many ways to do this. You may not want to do a full WCAG audit on each piece of functionality, but I’ve seen teams leverage checklists that address low hanging fruit. When you combine a bunch of fairly easy to execute manual checks with some automated accessibility checker, you will likely be able to address problems while they emerge. For instance, add that keyboard handler while you’re building the widget, rather than following a formal accessibility audit months after the feature initially launched.

Some checks you could include are:

• do the automated checks (for instance from axe-core, Tenon, Polypane or Siteimprove) return zero issues? Note, automated checks can only check 10-30% of WCAG issues, don’t rely on just automated checks
• can all controls in the feature be used with only a keyboard?
• can you still use everything if the browser is set to 400% zoom?
• for all form inputs, does the input activate when you click on the label?

Checklists have caveats though… the most important is to realise that “what’s most easy to check” is not necessarily the same as “what’s the most important to check”. It would be quite the coincidence if it was. But having said that, easy checks are probably the checks that are most feasible to include with each piece of functionality.

Level up on HTML proficiency

A large portion of issues I find in my WCAG audits relates to HTML and how to use it. Developers who know the HTML spec inside out are at a massive advantage when it comes to the WCAG compliance of the product they work on. Which elements to use when, how to build forms, what attributes exist for tables… it will all help write more accessible code.

For instance, developers who are aware that input-elements have an autocomplete attribute, will have no trouble meeting Identify input purpose (Success Criterion 1.3.5, which requires that attribute for form fields that collect personal information).

Ensuring new developers can bubble sort may be important to your business goals, but so is testing for HTML proficiency. Even, maybe especially, when you interview a full stack developer for your team, make sure you also interview for the HTML bit of the stack. It will help the team create accessible code from the start.

Wrapping up

In conclusion, with the right CMSes, checklists for every user story and high levels of HTML proficiency, teams can get a lot of their accessibility right early in the process. These all may all seem like no-brainers, but I’ve only seen very few organisations adopt them. I’m curious if others have more strategies for putting accessibility earlier in the process, please do reply via email or Twitter, or in the comments below.

---

Reply via email