What’s the common point between semantic HTML, the animations of your components and a dark mode?
Well, I guess the title of the article spoiled the surprise for you: all those elements (and a lot more) can make or hinder your website accessibility. Which is cool to know and all, but what does "accessible" really mean anyways?
Let’s take a little detour into the physical world
Just think of what an accessible city looks like. What comes to mind?
- Disabled parking places, wider than standard ones and situated in close vicinity of the building they serve.
- Sloped sidewalks next to the crosswalks.
- Elevators and access ramps instead of stairs, and railings on the stairs.
- Different sounds emitted by the trafic lights whether it’s green or red for the pedestrians.
- Ribbed pavement, that helps visually impaired people find their way around.
- You could also consider wider pavements and avoiding paved roads which are unstable.
- Etc.
You see the picture. The idea here is not to make an exhaustive list, but to point out how accessibility sets a global context to keep in mind that impacts lots of aspects, and can take lots of forms.
What you might not be aware of, is that most disabilities are invisible. Of course you see that woman in a wheelchair or the blind guy with a cane, but how do you spot a deaf person? How can you know that the man with the glasses, 10 meters away from you, is actually heavily near-sighted? How can you know if a person has a chronic disease that prevents them from doing everything an abled person can do? You can’t (except maybe if you creepily watch them for several minutes – and please don’t). And the conclusion of that observation is that all those infrastructures are actually useful for a lot more people than you would think of.
Now, another thing to have in mind is that, although they primarily focus on alleviating the lives of disabled people, all those features make the city also more accessible to everybody. And the reason behind that is, very simply, that anybody can be at least temporarily impaired, or impeded, at some point in their life. Elderly, pregnant women, parents with a stroller, teenagers with a broken leg: they benefit from most adapted infrastructures. And I say they, but I really should be saying you. Even if you’re not in any of these situations, I’m sure you feel tired from times to times, and you happen to take the elevator at the train station when you could have taken the stairs. Or that you see very easily the positive impact wider pavements can have.
Back to the web
Ok, but let’s go back to our subject: how is any of this relevant to web accessibility? Well, the whole picture translates very directly to the web: 1) there is a lot you can do to make the web a warmer, more welcoming place, 2) the possibilities take very different forms, 3) it is more important than you think, because you underestimate the number of people who need it, and 4) everybody, you included even if you're not disabled, actually benefits from them in the end.
How do others experience the web?
Before asking yourself what you should do, begin by understanding why you should do something. In other words, how do others experience the web? We can roughly distribute disabilities in 4 categories:
- Visual disabilities
- Auditory disabilities
- Motor disabilities
- Cognitive disabilities
Visual disabilities can mean:
- Blindness, which translates for a web developer into making sure a screen reader will be able to deliver meaningful content from your pages (alt text on images, every interaction should be reachable with the keyboard, using semantic HTML tags and ARIA when needed, the order of your HTML elements should be the semantic order of your page, ...).
- Low vision, which calls for bigger fonts and high contrast.
- Photosensitive condition, which can be tackled with a dark mode.
- Colourblindness, which implies that meaning should always be conveyed with something else than just color. A good contrast helps here too.
Want to know how it feels to use a screen reader? Check out this video.
Auditory disabilities call for:
- Subtitles on your videos
- Transcripts of your podcasts
Motor disabilities can be:
- Fine motor impairments, that for instance make it difficult to click on a button or a link if it’s too small.
- Lack of muscle control, making it impossible to use a mouse, but still possible to use keyboard navigation.
Cognitive disabilities are a wide spectrum:
- Vertigo or headaches provoked by motion sickness
- Difficulty to focus if a page is too loaded with elements
- Uncontrolled anxiety induced by unexpected behaviours, such as auto-plays, pop-ups, fancy scrolling behaviours, etc.
See this article, on the author's daily experience on the web or this other one, where the author experienced temporary impairment.
Of course this is only a sample of what is at stake, but I believe it already paints a pretty generic view. It is also a starting point to see how, by implementing those elements, you can improve the experience for everyone: subtitles on videos are useful for those who can’t or don’t want to turn on the sound (which is very common on smartphones), keyboard navigation for anyone who doesn’t want to go back to their mouse for every action, dark modes are more and more asked for just by sheer preference, auto-play and pop-ups are a plague anyways, etc.
When you’re reading lists like that, implementing everything, and even more so implementing everything properly, can feel like a daunting task. So let me tell you this: no-one expects you to do everything at once. Take it step by step, one feature at a time. Learn how one thing works, put it into practice, and little by little you’ll learn more and won't have to think about it too much. I myself am by no means an expert in the field – but I try to be aware of these considerations when coding.
Please bear that in mind as we enter the next section: you don’t need to go from not knowing anything to mastering everything. You’ll make some mistakes, you won’t be able to implement everything, and it’s fine, as long as you’re willing to learn and improve your knowledge. Doing a little to make the web a better place will always be better than not doing anything at all.
How do I implement that?
SEMANTIC HTML
BLOCK-LEVEL ELEMENTS
You know about semantic HTML, but do you use it? You might have learnt about <main>, <aside>, <article>, <nav> and the others at some point, maybe very quickly in the first week of a bootcamp, but then you focused on other things and never thought about them again. Now <div> is your best friend, and everything is a <div>. Let’s question why they are actually useful and why you shouldn’t set divs everywhere.
For a screen reader, those tags contain, well, semantic meanings. Imagine a page full of divs: how could an assistive technology know which div does what? I’m sure you gave them very explicit class names, like .container and .content. You’ll agree with me that it’s basically useless in order to distinguish their uses. Note that even if you have more meaningful classes, like .header and .main, there is no standard for it, so you can’t expect the screen reader to understand what you mean with that. Plus, if those are the names of your classes, you might as well use the actual HTML elements.
On the contrary, since it’s standard, what your <header> is is very clear, and will be clearly presented as such to the user. Similarly, a <nav> will be notified to the user as a navigation element. That makes it much clearer than just knowing it’s a list.
Additionnally, search engines love semantic HTML too, and your site will end up much higher on Google if you use appropriate semantics. See? I told you accessibility benefits everybody.
COMPONENTS ELEMENTS
But there is more to semantic HTML than those block-level elements. A <button> is not a link <a>, and vice versa. If you don’t know the difference: a link should take you to another page, while a button suggests an interaction (submitting a form, opening a pop-up, counting the sheep…). If your button says "Discover who we are", chances are it’s actually a link to your "About" page: use a <a> and style it like a button if you want to. Conversely, if you have a "Read more..." styled like a link that expands your article like an accordion, consider it is a button. A good rule of thumb you’ve already heard but may forget from time to time: always use CSS to style, not HTML elements.
TITLES
Other semantic HTML elements include the title tags, <h1> to <h6>. In summary, here are the basics you should know:
- You should only have one
<h1>per page. This is your main headline, the page title, what makes it different from another page on your website. Everything else on the page is a subtitle. - (Sub)titles should be used incrementally. After an
<h1>comes<h2>, and after that comes<h3>, not<h5>. - Here again, don't use them based on what they look like; use them based on their semantics and style them afterwards.
- It is also a good SEO practice (Search Engine Optimization, the technique to make Google happy and appear in the 5 first results).
WCAG, ARIA, A11Y: WTF?
You probably heard before of WCAG compliance, ARIA or a11y, but their meaning and purpose might be blurry to you (and who could blame you with all those obscure acronyms?).
WCAG stands for Web Content Accessibility Guidelines. Those have been formulated by the World Wide Web Consortium (W3C) in 1999 and have been evolving since then, just like the web in itself. The last version of the recommendations (2.1) was published in 2018 and the very complete documentation is to be found on https://www.w3.org/TR/WCAG21/. It gives indications on the expected behaviour of pretty much anything that can be found on the web, in order to be as accessible as possible (levels A, AA, AAA). These have an impact on things from alt text to focus states, modals to videos, keyboard interaction to color contrast. On some of these subjects, here are some good reads:
- How to design good focus indicators? Sara Soueidan gives extremely valuable advice.
- Should you use
px,emorremunits? This article by Josh Comeau will help you wrap your head around the differences between them. - Think about implementing
@media (prefers-reduced-motion)and read why it is important and how to do it. - Think about implementing
@media (prefers-color-scheme: dark).
ARIA – not the Game of Thrones character – stands for Accessible Rich Internet Applications. It is one of the ways you can make sure your content is accessible to as many people as possible. It allows you to let screen readers know what they should say when they encounter a specific element on your page. Remember those semantic HTML tags? They use ARIA under the hood without you having to think about it, and that's the reason why they should be used. It is a powerful tool to make sure your website is understandable by everybody, even when used under different conditions. I won’t go into too much details about it, but please remember though that no ARIA is better than bad ARIA! While it is powerful and a good practice to implement it where it needs to be, it can also do a lot of harm to your accessibility if you don’t use it properly. Always prefer an accurate semantic HTML tag if possible. If not, then ARIA implementation of roles and other attributes is a great way to make your website more accessible:
- an input wrapped within a
<div role="search">makes it clear that it's a searchbar (otherwise it's just a text input for a screen reader) - a
role="dialog"means there's a component set above everything else on your page (called a dialog or modal), and the user should not expect to be able to interact with anything else outside that modal. That last part also means that setting the role is not enough, you need to implement everything around it: 1) trap the focus inside the modal (i.e. disabling the page behind it); 2) the attributearia-modal="true"tells the screen reader that, when opened, everything behind the modal is inert; 3) have theESCkey close the modal and return the focus to where the user was before opening it; 4) possibly make it so that a click on the area around the modal closes it too... - attributes such as
aria-label,aria-labelledby,aria-describedby, etc. can also occasionnally be used to be more explicit and help make sense of what the element is about. See for instance how it can be used with<section>tags to improve your accessibility on this video by Kevin Powell. - For more examples, I highly recommend you to check this page that identifies patterns and gives very thorough examples of how to implement ARIA in your projects.
The A11Y project aims at making accessibility easier. They offer help, posts, resources to help you understand how to make stuff accessible and why it matters. Why A11Y? Well, this one is actually self-explanatory and easy to remember, so I guess you didn't actually ask the question, but it’s also a pretty cunning way of writing a*ccessibilit*y: just count the letters.
To summarize
I hope you learnt some things along the way! The idea of this article was mainly to set a general overview of what web accessibility means, why it matters, what it looks like, and give some leads on the tools at the disposal of developers to tackle the issue. Of course, this is but scratching the surface. I didn't discuss lots of existing features and important things to set up. But now I'll leave it to you to dig the subject.
In addition to the resources scattered across the article, I also advise you to make your own list of experts and not-so-experts developers who talk about accessibility and follow them, either on social media or by checking the RSS feed from their blog if they have one (and yes, RSS is still pretty darn useful in 2022 :) ). It's always easier to learn things over the span of several months, just by reading / listening to great pieces. And this whole accessibility thing might start to look simple over time...
Top comments (1)
[[..PingBack..]]
This article is curated as a part of #60th Issue of Software Testing Notes Newsletter.