This text is based on my perspective as a new frontend developer in Sweden.
It's hard to measure, but around 20% of Sweden's adult population has a disability/variation that makes it difficult to use the internet. It could be vision, motor skills, or cognitive function that works differently or is not at its peak.
20%. That's every fifth person. Let that sink in for a moment.
The Internet has quickly become a given for us. Many of us don't even know what it was like before the internet. It was in the 90s that private individuals began using the internet, and Tim Berners-Lee then combined many different technologies to create the HTTP protocol, the HTML language, and thus the World Wide Web, as we know it today.
Audioeye has analysed nearly 40,000 large company pages to create the Digital Accessibility Index, a review of how accessible the internet is based on WCAG. The greatest difficulties exist in images, links, and forms:
- 56% of the images are not accessible to people with visual impairments.
- 64% of the pages have links that are unclear to people with a form of disability.
- 1 in 4 forms and input fields lack descriptions, making them unclear to people with a form of disability.
How can we do better?
Images and alt attributes
Images need an alt attribute with text that screen readers can read aloud for people with learning difficulties, vision problems, or difficulties processing sensory impressions.
Remember to be descriptive when writing your alt text and start with the most important thing; a bit like you would describe the image in a book. Don't start with "picture of..." or similar, the screen reader already knows that it's an image and will say so.
If the image is decorative or otherwise described, such as a picture of an ingredient list that is also texted at the picture, you can leave the alt text blank by using alt="". This will make the screen reader ignore the alt attribute. So, DO NOT remove it completely because some screen readers will read the image file name if the alt attribute is not included at all.
Links and context
Links need to make sense outside of the surrounding context, and this is primarily for people who use screen readers as they often navigate pages by jumping from link to link. But also, people who have difficulties processing sensory impressions find it easier to navigate.
The simplest way to create better links is to write more than "read more", or "click here". It's actually okay to have a whole sentence in a link, such as "Read more about cat behavior", or "See all our new shoes for the season".
If you have an image as a link, the alt text should describe where the link goes instead of what the image is showing.
Another option is to use the aria-describedby attribute along with an id.
<a aria-describedby=”foo”>A link</a>
<p id=”foo”>A screen reader will read this text before the link</p>
Forms and label
Forms and input fields need a <label> element that screen readers can read aloud to provide context and make the purpose of the field clearer. A bonus when using label is that you can press the text to activate the input field, which is great if you have difficulties with fine motor skills.
<label for="cheese">Do you like cheese?</label>
<input type="checkbox" name="cheese" id="cheese" />
Keyboard navigation
The goal of keyboard navigation is to make it as simple as possible since it can otherwise require many clicks to get through a page. It's easy to try it out yourself:
- TAB - Next element
- SHIFT+TAB - Previous element
- ENTER - Activates the active element
- SPACE - Activates the active element, toggles checkboxes
- ARROW UP & DOWN - Moves you between radio buttons and similar
- ARROW LEFT & RIGHT - Sometimes moves you between links
- ESC - Closes modals, moves you back to the previous element
Write your HTML in an order that makes sense without styling - yes, all elements are straight up and down. That's how the page is perceived by people who use screen readers or navigate with the keyboard only.
It's important to provide the ability to skip over long menus and recurring content. This can easily be done with a link that links to another element. It's also easy to hide by only letting it be visible when it's in focus.
<a class="jump-to-content" href="#main">Skip to main content</a>
.jump-to-content {
background-color: white;
display: block;
height: 0;
overflow: hidden;
position: absolute;
text-align: center;
}
.jump-to-content:focus {
background-color: orange;
color: #000;
height: auto;
padding: 2rem;
position: static;
}
Mark clearly what's in focus with the :focus state, showing where the user is on the page, and should not be confused with :hover. It's enough to apply a thick border and a background color with contrast.
a:focus, input:focus {
border: solid black 3px;
border-radius: 3px;
background-color: yellow;
}
Allow the user to actively open a tab instead of it opening automatically.
Test your page also with the keyboard so that you can tab through everything from the top to the bottom and back to the top again. Make sure that all forms and other functions work. Does it feel tedious?
Continue to make the page easier to navigate with the keyboard.
Bring attention to changes
When something important happens on the page, it needs to be highlighted in some way other than just visually. Mainly for users with impaired vision so that they know when, for example, something has been added to the shopping cart or if a form has not been filled in correctly.
The aria-live="" notifies when an element is updated (not created) and it can have one of three values:
- assertive - Used only if it's something time-sensitive or otherwise critical that requires the user's immediate attention. This should be used sparingly as it can be extremely disruptive as it interrupts everything else. Think of a popup you can't click away.
- polite - It's the most common and is used when it's an important but not so critical update.
- off - Default value.
Example:
<label for="name">What's your name?</label>
<input type="text" id="name">
<p id="welcomeMessage" aria-live="polite">Hello...</p>
When the user enters their name in the input field, the <p> element will be updated, causing the screen reader to read out what's inside it, after it finishes reading what it's currently reading.
Some of the values that the role="" attribute can have also work as a live region:
- log - Used to log things like chats, updates in games, and the like. A log, essentially.
- status - A status area, people using screen readers have a command to read the status, so it's always easily accessible.
- alert - Functions similar to aria-live="assertive" and should therefore be used sparingly and only for warnings and error messages.
- progressbar - Used in conjunction with aria-valuemin, aria-valuemax, and aria-valuenow to define and update a progression.
- marquee - Text that updates like a clock, such as a stock price.
- timer - Used for all sorts of clocks, timers, etc.
I could go on writing a lot about this, but then this section would take over the article, so I recommend reading more on your own.
Other things that make a big difference
- Set the text size using rem so that the text is scalable with the browser's settings and zoom.
- Don't use too low contrast, especially between text and background.
- Don't use only color to convey information, include text and/or symbols.
- Give the page an <h1> title that describes the content or purpose.
- Specify the language of the page with <html lang="en">, you can use the lang attribute in other elements as well. If you have different languages in the text and attributes, such as a language selector, you can do it like this:
<a title="Spanish" href="qa-HTML-language-declarations.es"><span lang="es">Español</span></a>
- If something is missing or incorrect in a form, the error message should be displayed close to the relevant field and describe what went wrong.
- If a link is intended to be shared, make the address short and descriptive to make it easier to interpret the content.
- If the content on a page could become outdated, you should include when it was published and/or last updated. This is to determine how current the information is.
- Include information about who is responsible for the page in the footer or header, so the information is always available. It's also good to include it in any downloadable documents. Feel free to use metadata too:
<head>
<meta name="author" content="Chris Mills" />
<meta
name="description"
content="The MDN Web Docs Learning Area aims to provide complete beginners to the Web with all they need to know to get started with developing websites and applications." />
</head>
- A description of your mission or business idea helps to put the page in context and increases credibility. This is suitable to include under "About us" or similar in a menu.
- Don't use <div> if there are other elements that can do the job.
Checklists and tools
All accessibility guidelines are not relevant to every website, but the following pages have good filtering, descriptions, and checklists that you can use:
You can use Lighthouse, which is built into Chromium DevTools (the same menu as the console and elements), and tests, among other things, how fast the page loads, accessibility, and SEO. If you use Figma, there are plenty of great plugins available.
I'm tempted to link a lot of tools here, but it may not be very interesting to read that list, and the tools, pages, and plugins available can change at any time. After all, we are Google ninjas.
Why should I care?
Everyone benefits from accessible pages with clear information and low cognitive load. It's enough to be tired and stressed to find it difficult to navigate a page and take in the information.
There was a study on how to make school lunchrooms more inclusive for everyone, and it's not just students with disabilities/variations who benefit from a calmer and clearer environment, but all students and even adults benefit from this. Just as a lunchroom can have many impressions and unclear "stations" and routines, a page can have many impressions and unclear links and purposes. Study: The pursuit of an inclusive school meal (sv) s.6 & 10 (actual page number s.28 & 32) by Sara Frödén and Charlotta Petterson by Örebros University, 2021.
One year ago (2022), about one in ten residents in Sweden lived in a digital exclusion due to not being able to obtain BankID. This has made them excluded from over 6,000 services that they are entitled to and that are obvious to most people. Fortunately, this has started to change in recent times.
Most of us need accessible webpages, more or less, temporarily or permanently. I have learned a lot during the time I have been writing this article and will use it as a starting point in the future for accessibility on the pages I create.
We simply need to think about accessibility more because we never know who has difficulties, it could be a colleague, a cousin, or the friendly neighbor you often chat with.