What is web accessibility ?
Before we dive into what web accessibility is, we should first understand what the word ‘Accessibility’ entails.From my knowledge, “Accessibility means the ability of everyone regardless of their condition to have access to something (e.g internet, transport system).” It's not a switch that can be turned on and off. We need to write semantic HTML right from the start.
1. Add Alt Text to All Images
Adding alternative text for images is the first principle of web accessibility.This text acts as a replacement for the image if it fails to load. Adding alternative text to the image helps the users who use screen readers. The screen readers will read the alt text and provide the information to the non sighted users.
Alt text should answer this question: What is the content conveyed by the image?
Note: If the image is purely decorative or if it creates redundancy because the surrounding context already explains the content. Then adding an empty attribute will make screen readers skip it. If you don’t write any alt text, some screen readers will read the file name to the individual. That’s the worst experience you can provide.
2. Forms should be accessible
Although building forms can be a difficult task at times, making them moderately accessible isn’t as complicated as you might think. Filling forms on websites and apps for people with disabilities and even for people without disabilities should always be with ease.
- The first rule to create a truly accessible form is to use native HTML form controls.
<input type="text">
<input type="radio">
<input type="checkbox">
<button>Submit</button>
Since we use the native HTML controls, the name, role, and state of the elements are exposed by default to all assistive technologies. But if you using div's to build custom elements, make sure you do not forget to add ARIA attributes like aria-label, aria-checked, role= “radio” etc.
- Make sure to use Explicit label wherever possible. 👇
<label for="fname">First Name:</label>
<input type="text" name="fname" id="fname"><br>
<label for="lname">Last Name:</label>
<input type="text" name="lname" id="lname">
If explicit label is not being used make sure to provide every form control a label using aria-label, aria-labelledby.
For more information read visible label
3. Ensure all interactive features are keyboard-accessible
The most important goal of keyboard accessibility is to make every interactive element, such as links and form controls, available with the Tab key. This is how keyboard-only users navigate through a web page. Testing your website for keyboard accessibility is actually pretty easy: just press the Tab key and navigate from the top of the page to the bottom, highlighting active elements as you go.
People who are blind need full keyboard access. Period.
— David Macdonald, co-editor of Using WAI ARIA in HTML5
Common Keys Used in Keyboard Operation of Web Pages and Web-based Applications
Tab – move to the next link, form element or button.
Shift+Tab – move to the previous link, form element, or button.
Enter – activate the current link or button.
Space – check or uncheck a checkbox form element. Will also activate a button that currently has focus.
Up/Down arrow keys – move between radio buttons or, in some cases, menu links.
Right/Left arrow keys – in some cases, move between menu links or adjust sliders in audio and video plugins.
Escape – Close the current modal dialog or dropdown menu and return focus to the element that spawned it.
If you are interested in reading tips on how to improve your keyboard navigation. Read here
4. Design usable focus states
Have you noticed the blue outlines that sometimes show up around links, inputs, and buttons? These outlines are called focus indicators.
Browsers, by default, use a CSS pseudo class to show these outlines on elements when they’re selected. Your designers might find these default focus indicators not very pretty and be tempted just to hide or remove them. However, if you get rid of this default style, be sure to replace it with something else.
Focus indicators help people know which element has the keyboard focus and help them understand where they are when navigating your site.
5. Use correct markup on your content
When writing semantic markup, we use HTML tags to tell browsers something about the contents of the element. In semantic markup, tags are no longer just a way to get content to show up on a web page in a human-readable format.
The tags themselves become a way to tell a machine (whether a browser, a computer, a smartphone, or another smart device) something about the meaning of the content.
Headings mark where the content starts — they’re tags given to text to define its style and purpose. Headings also establish the hierarchy of the content of the page.
Titles with big font sizes help a reader understand the order of the content better. Likewise, screen readers also use heading tags to read content. This way, people with low-vision get an overview of the page by reading each heading in a hierarchal flow.
It’s important to use proper structural elements when you develop a site. HTML elements communicate to the browser what kind of content they contain and how the browser should render or treat that content. The components and structure of a page are what arranges an accessibility tree. This tree is what powers screen readers which are used by people who are blind so they can “listen” to a page.
Not using markup correctly affects accessibility. Don’t use HTML tags for a style effect only. Screen readers navigate web pages by heading structure (true headers, not just text that is styled big and bold) hierarchically. The people that use your site can listen to a list of all of the headings, jump the content by types of titles, or navigate directly to top-level headings <h1>
6. Do not use disabled attributes on buttons
If you use disabled attributes on button it removes it from the accessibility tree and therefore the screen readers will never know if the exists on the page.
To solve the above problem make sure you style the button visually to make it look disabled and can use pointer-events: none to prevent the clicking on button.
But how do I make sure when the screen readers users use the web page they should understand that the button is disabled.
The solution to your problem 🤘 is using aria-disabled attribute
<button id="target" aria-disabled="true">target</button>
7. Use display: none CSS property or hidden attribute carefully.
Often there might be a situation that you might want to hide something on some click of the button or link. In this case do remember if you use display: none or hidden, it will also be removed from the accessibility tree. Setting display: none hides the content but also removes it from the accessibility tree so screen readers won’t read it.
There might be situation when you might want to display something only for the screen reader users and want the content to be visually hidden. How will you handle this ?
There's great solution 👇 to hide content visually while keeping it in the accessibility tree for screen readers:
.sr-only {
border: 0;
clip: rect(0 0 0 0);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
width: 1px;
}
Hiding Content for Screen Readers
Some content is not important for understanding a web page, but is added to make the design more visually appealing. For example, icons and glyphs can provide a nice visual polish, but tend to be unhelpful — and sometimes downright distracting — for screen reader users. In this scenario we’ll want to hide the content from screen readers while showing it to everyone else.
In this case we’ll use the aria-hidden attribute. aria-hidden is a boolean attribute so it can be set to true or false. Setting the attribute to false is the same as not including it at all, so you’ll generally want to set it to true and use it like this:
<div class="my-glyph" aria-hidden="true"></div>
8. Visual Order & Dom Order should always match
Implementing a logical tab order is an important part of providing your users with a smooth keyboard navigation experience. Screen readers and other assistive technologies navigate the page in DOM order. The flow of information should make sense.
Lets see an example
<ol>
<li>Basket Ball</li>
<li>Foot Ball</li>
<li>Throw Ball</li>
</ol>
That HTML ends up in the DOM that way (and thus how it is is exposed to assistive technology), and by default, those list items are also visually shown in that order. In most layout situations, the visual order will match that DOM order. Do nothing, and the list items will flow in the block direction of the document. Apply flexbox, and it will flow in the inline direction of the document.
But flexbox and grid also allow you to muck it up. Now take this:
ol {
display: flex;
flex-direction: row-reverse;
}
In the above case, the DOM order still makes sense, but the visual order is all wrong.When you use the tab key to move through the content, there is a disconnect between the visual order and the keyboard navigation (DOM) order. In this simple example it is still although it wrong, but in a situation where flex-box is used to layout a complex interface it could make things horrible & unusable for the users using assistive technologies.
Solution is providing tabindexto the element so the visual and dom order matches
But the problem is that tabindex is scoped to the document. If the above code were included in a page, it would completely hijack the tab order. The three items with tabindex would be the first three things on the page to receive keyboard focus, irrespective of their overall location in the DOM structure.
To read more check out this awesome article
9. Use color with care.
The color contrast between background and foreground content (that is, usually text) should be great enough to ensure legibility.
There are several tools you can use to evaluate color contrast, which will assist you in making your page as visually usable as possible to individuals with low vision or varying levels of color blindness.
10. Make dynamic content accessible.
When web page content updates dynamically (i.e. without a page refresh), screen readers may not be aware of whats happening on the page. This includes screen overlays, in-page updates, popups, and modal dialogs.
Problems:
Keyboard-only users may be trapped in page overlays. Magnification software users might be zoomed in on the wrong section of the page.
Solution
These functions can easily be made accessible. Options include ARIA roles and alerts.
Ensure that video players do not auto-play (non-consensual sound), and that the players can be used with a keyboard. Additionally, all videos must have options for closed captioning and transcripts for the hearing-impaired.
If your site contains a slideshow, make sure that each photo has alt text and can be navigated via the keyboard. If you are using any unique widgets (such as a calendar picker or drag-and-drops), be sure to test for accessibility.
This is one of the great article I found on internet which I recommend
Reading resources 📚
WebAIM Articles, resources, and training on web accessibility.
Color Accessibility Workflows: Some neat examples to nail the colors in your design by Geri Coady.
Useful tools
WebAIM Color Contrast Checker: Great contrast color checker that gives you results in real time for regular and large text.
Inclusive Components: A pattern library in the form of a blog, with a focus on inclusive design. Each post explores a common interface component and comes up with a better, more robust and accessible version of it.
Color Oracle: A free color blindness simulator for Windows, Mac, and Linux. It shows you in real time what people with common color vision impairments see.
Vox Product Accessibility Guidelines: A comprehensive checklist for designers, engineers, and project managers.
AXE Google Chrome Extension: Test any site for accessibility violations using the Chrome inspector.
Contrast: A macOS app for quick access to WCAG color contrast ratios.
Develop responsibly. Thank you.
Top comments (2)
What a fabulous first post
Nice! 👋