Accessibility: Why and how you should care
We are doing it wrong.
Or often, not at all.
I’ve been working as a developer at digital agencies for over 10 years now. All the projects I touch have a big focus on design, motion and performance, while trying to bring to life unique, smooth experiences on the web. We’re always aiming for the highest standard of quality, and pushing new optimization techniques as far as they can go. Whether it’s for an amazing cause, to discover the American National Parks, or to review your year in music, these projects draw a lot of attention.
And sadly, if there’s one territory where we all don’t spend as much time as we should, it’s making our projects accessible.
Full disclaimer, I’m not an accessibility expert. I’ve always been interested in that topic though, making server-side rendered websites since day one and trying to have good semantics. Obviously, that is not enough. At Stink Studios, we recently started doing accessibility audits on the last few websites we released, which gave me the chance to learn more about these challenges.
Today, I want to share my experiences. The following content may contain errors, or need complementary information. Please, let me know in the comments!
Why do it?
Seems like a dumb question, but there are actually a lot of reasons.
It concerns everyone
While accessibility might make you first think about people with disabilities — blindness/low vision, motor dysfunctions, etc — it also concerns every one of us, at some point in our lives. Just think about it (feat. real world examples):
- Taking the stairs in a subway station with a stroller. No elevators or ramps? Have fun.
- Forget your glasses at home before going to work? Have a good day!
- Injure your hand after a weekend ski trip and need to carry groceries? Good luck with this one.
And so on. Accessibility is not only for those with a diagnosed disability, but it’s for everyone because everyone could be impacted at some point in their life.
Accessibility is also not just about screen reader and keyboard users. It’s making sure a text is readable, it’s making a website load fast, it’s about the user experience of the website you’re building.
It’s the law!
Laws about accessibility were adopted in the US in 1973 (full list here : The US Rehabilitation Act of 1973, Section 504 of the US Rehabilitation Act of 1973…). These laws concern the Government, but also in some extents the public and private sectors.
Also, EU is coming at you.
It improves everything else
Working on making your website accessible will likely impact the performance, SEO, and design in good ways.
It doesn’t take that much time to minor adjustments once you have a few good habits in place, and it can make a huge difference.
A team effort
While my job is to focus on the dev part, it’s essential to also take part in the UX, Design and Production process to some extent.
Developers ultimately build the end product, and therefore our feedback is essential throughout the whole process, from start to finish.
So please, let’s engage in conversations. Let’s talk with everyone about the feasibility of a specific solution. Let’s argue over a focus state. Accessibility is a topic that everyone should be aware of.
- Is the navigation accessible at any time during the user experience?
- Does the modal have a close button? A back button?
- We need an extra week to make theses pages fully navigable on keyboard!
- Does the form have a submit button, and how does it handle errors?
- How does this component work on mobile?
- Do the CTAs and buttons have hover/focus state?
- Is the font contrast ratio enough? Aka is it readable?
- There’s a list of items. How does it work when there’s 0 result? One? An infinite number of results?
Also, it doesn’t mean that we have to fall back to very classic and common layouts/component. We can be original and still come up with something accessible.
Let’s work on delivering specs. Let’s not be shy on challenging the UX about how a specific component works, or ask designers about how a page behaves on a certain breakpoint, or talk about the information architecture of the pages… It’s team work 🤜🤛
Update: After publishing this article, I found this excellent article about Designing for accessibility. Go check it out!
But what about code?
Let’s start with some basics: the semantic. The semantic is part of the accessibility. Really good semantics are mandatory for a good accessibility (and SEO).
A few best practices/common mistakes
Headings
Make sure the information architecture is meaningful and not broken. I personally use the Web developer chrome extension, but feel free to use any equivalent tool.
To see your document outline, open the extension, go to the Information tab, then click on “View Document Outline”.
Here’s an example on chobani.com:
Everything looks right at first. No missing headings, but when we look at the actual design, we can see that the <h3/> tags are not necessary.
Therefore, replacing these tags with <p> or <span> tags would be the right move. Don’t use extra <h/> tags! The document outline is supposed to only highlight the main sections. Based on the type of projects I worked on, most of the time, it only needed an <h1/> and a few <h2/>. Of course, it doesn’t apply to every project/page — it’s only based on the kind of website/page layouts I worked on — but these examples are more asset driven than content driven.
One last thing we noticed was the copy. We designed eyebrows to be small and titles to be big, so we naturally put an <h1/> tag on the titles. Turns out, the client use them more as a “design callout”, while eyebrows contained more meaningful content for the user.
<button/> !== <a/>
<button/> and <a/> tags automatically have a focus state when a user is tabbing through a website (or clicking on a <button/> ), so it’s essential they are used in a good way.
A <a/> tag should be used for linking to a page or for a specific action (mailto, tel…). While using href="#id-container" is acceptable to target a specific section of the current page, it’s not acceptable to use it to simulate a button. When you code an external link, make sure to add the target="_blank" and rel="noopener" attributes for performance and security reasons, and give an indication to the user (either visual and/or with a hidden label) that they are navigating to another website.
When do you use a <button /> ? Every time you want to trigger a JS action: opening a hamburger menu, a carousel item that opens a modal, a drawer, submit a form, close a modal… It’s not a <span/> , not a <div/> , not a <a/>, but a <button/> !
<div /> and <span />
Yes, pretty obvious but trust me, it’s something I’ve seen a lot.<p /> are for paragraphs. Not <div/>! You want 2 paragraphs?
Do
<p>My 1st paragraph.</p>
<p>My 2nd paragraph.</p>Don’t
<p>My 1st paragraph.<br/><br/> My 2nd paragraph.</p>List
- Want to list things?
- A list of links?
- A nav?
- A carousel?
Use <ul/> / <li/> !
Form
Any input, even a single input, should be in a <form/> .
A <form/> should use a <fieldset/>(used to group related elements in a form), and a <legend/> if needed (defines a caption for the <fieldset> element)
A <form/> has an action (url where the form is submitted to) and a method (get, post…) attribute. Even though you are probably doing the form submission in Javascript, these attributes are standards and make your form work without JS.
A <form /> should have a <button type="submit" /> for the submission.
Feel free to start use the required, pattern, maxlength, disabled… attributes, as well as the different input types (email, phone…). They are mostly implemented by the browsers today, and provide a baked-in validation system when a user submits a form, with a better accessibility overall. For instance, type="phone" will open a special keyboard on phones to display numbers only.
Meta tags
A few essentials:
- Don’t forget the doctype!
<!DOCTYPE html> <html lang="language_iso_code" />: The HTML lang attribute is used to declare the language of a Web page (could be used for a portion of a Web page too). This is meant to assist search engines and browsers.- If you need to support IE 9, IE 8, or need to override IE’s Compatibility View Settings for intranet sites,
<meta content="IE=edge" http-equiv="X-UA-Compatible" />should be the first tag in your<head>.
🤷🤷🤷🤷🤷🤷🤷🤷🤷 - Don’t forget to put
<meta charset="UTF-8" />right after to set up the current charset for your Web page. - And of course,
<title/>,<description/>, social tags…
And so many more…
<nav> , <header>, <footer>… These tags are here, use them!
Keyboard navigation
Keyboard navigation is usually one of the most neglected part of a website, along with screen reader accessibility.
While clients and designers often dislike the basic outline a focus state gives button/links, it’s still essential to have one. Here’s the design challenge:
It’s not mandatory to use the outline to indicate a focus state, but you can either change the style of the outline, or find any other design solution as long as the focus state exists and is different from the normal (and hover preferably) state.
On top of the outline and focus state, the keyboard navigation has a lot of other challenges.
For instance, how painful is it to tab all the way through a website to be able to access the links in the footer? Or to directly access the content? One best practice is to make a link appear only when a user starts tabbing, to directly jump to the content/footer. For instance, on nytimes.com:
Let’s take an other example: a modal.
When opening a modal, if nothing is coded to improve the keyboard navigation, the user experience could be really poor: the focus stays on the main content behind the modal, making impossible for a user to actually tab through the current content displayed on the screen.
One best practice here is to remove the focus off of the main content and immediately put the focus on the first element on the modal, preferably the close button. A user can now directly close the modal by hitting enter, or tab through the modal.
🗒Feel free to also support the escape key, and more generally, other keys (left/right in the context of a carousel, spacebar to play/pause a video player…)
But it’s not done yet.
When a user closes the modal, we want to put the focus back on the button the user just clicked on!
That was just an example, but we can go on and on: carousel, dropbox…
In practice, try to navigate using only your keyboard to go from page to page, open modals, test forms… And see what makes the most sense to optimize the user experience.
And yes, it takes time.
Screen readers
Screen reader navigation is also essential, but mostly forgotten by developers. A few basic best practices could drastically change your application accessibility.
Images and alt attribute
Most of the time, developers forget to put analt attribute, or fill it with bad or useless content.
Here’s a rule: put an alt attribute only if it gives additional information and if the image doesn’t act as a background. It’s mostly a matter of context. A same image could contain a different alt attribute depending on its function.
If you don’t need an alt, just make an empty one, but always have one.
Let’s play a game.
Alt or not?
“Apricot” already gives the information you need about this image. Putting an alt would repeat the information or make useless noise for screen readers.
Alt or not?
The image contains a text that needs to be accessible for the screen readers.
If an image is really used as a background, please do. Use background-image (on a pseudo-element if necessary) instead of an <img/> tag!
Aria attributes
This is a huge section to cover.
Aria attributes define ways to make websites and applications more accessible by creating points of navigation between components, giving suggestions and directions on how the current application is behaving or could behave.
While it doesn’t make sense to go over all of the different attributes, let’s look at a concrete example of a component we are using 99% of the time in a project: a hamburger icon and its modal menu.
To illustrate this example, here’s the ones we implemented for stonewallforever.org
Hamburger Icon
This example was coded in React, but is simple enough to illustrate the render.
aria-controls: An id or list of ids of the container(s) the button is linked to. Only put thearia-controlsattribute if the container is actually in the DOM. In our case, it would open the mobile menu container that has anid=”menu-mobile”attribute.aria-expanded: Actual state of the container linked to this button.trueorfalsedepending if the menu is currently open or not.aria-haspopup: Indicates that the element has a popup context menu or sub-level menu.
🗒 “Open menu” is visually hidden in CSS using the text-indent technique, and the button has a background of an hamburger menu icon.
Always try to have a descriptive label, or if you can’t, use the aria-label attribute.
🗒id=”menu-hamburger” is important for the menu modal container.
Menu Modal
<nav/>: Navigation containeraria-labelledby: Id of the<button/>that actually controls this container.role: Indicates the current role of this container. It’s primary role is to be a menu.
🗒The close <button/> is the first children of the container so we can put the focus on it as soon as we open the menu
🗒We used the React <Transition> plugin to show/hide the menu based on the current app state.
So…
There is a lot to cover. While this could look very basic to some, it could be fairly new to others. I’ll keep on working on these challenges, so if you have any resources/recommendations, please send them over!
