A website, here, is a collection of pages, made of HTML, CSS, and JavaScript, presented usually over the Internet to users’ web browsers.
The prime directive is to communicate with users. The user will generally know what they would like rather than what wouldn’t help or even hinder their experience. Some users may have different ideas of what is “accessible” versus other users. In cases like this, you’ll either need to choose between the two ideas, or give the users a choice between the two (preferable). When it comes to accessibility, choice is never a bad thing. Your users will thank you for giving them something that makes their own experience enjoyable, productive, or both.
This section will concern users who have either only light perception or cannot see anything at all. People who have limited vision will be addressed in another section.
Use HTML for content, not layout or looks. Tables should only be for the display of data, not for layout of regular information. If you want information to be in columns, do that using CSS.
Headings are for sectioning out your page. Try to only have one heading at level one, as the title of the page, article, or main content. This allows blind users who use only headings to find the main content of a site more quickly, and for those who use landmarks to do the same thing with the Main landmark. Keep in mind, though, that many screen readers only allow users to move from landmark to landmark, so if you’ve got a Navigation landmark for your navigation bar, then an Aside landmark for some complementary content, it’ll take more key presses to find the Main landmark than it will the heading at level one.
Landmarks are for more screen reader specific navigation. A main landmark denotes the main section of the page. Landmarks are for dividing your page into regions for faster navigation. They can be very helpful in news sites, where the article landmark allows the user to move from one article to the next, if the screen reader supports the movement from one Article to the next.
Within form controls, like buttons, edit fields, check boxes, and radio buttons, it is important to give them textual labels using the label tag. Screen readers will read this to the user.
Be sure to label widgets simply and briefly. It’s better to label a button “close” than it is to label it “A green close button on a blue background.” Do not add the widget’s roll to the label either, as the browser will know what kind of widget it is, and will communicate that to the screen reader.
Placeholders should never replace labels in forms.
You may have heard of ARIA, which allows a web developer to control a lot of what a screen reader says and does on a site. However, configuring ARIA can be brittle and painful, requiring a lot of manual intervention when something breaks. It is much easier to instead use simple, pure HTML, which screen readers and browsers are already good at understanding. If you have to use ARIA, be sure to have users test your site to see if they can use the functions built with ARIA.
Images must contain an “alt” attribute with a description of the image. It doesn’t matter if your descriptions are exquisitely vivid and detailed; what matters is that you get the point across. For example, “An orange kitten curled up on a windowsill in a sunbeam” is good enough for most cases.
Leave the “alt” empty if your image is just decorative for sighted users and doesn’t add any value to the content.
Be careful when you use images inside buttons or links without text. Don’t describe the image here, but which action will be initiated when the user interacts with the element.
This is also important to make your site accessible for sighted people in poor countries who cannot have good Internet connection and will have images disabled by default.
If there is a widget, like a paragraph, in a different language, use the “lang” attribute to tell the screen reader which language to speak in. This helps in language-learning sites, or even social networks which allow multi-lingual posts.
This section will concern users who have color-blindness or color vision deficiency and cannot distinguish certain shades of color.
Don’t rely on color to give important information. Color-blind users may not perceive the difference. Use patterns, icons or text instead.
If you give different color options to the user (for example, when they are buying a T-shirt), include text with the name of each color in the text description so they can know which one they are choosing even if they cannot perceive the difference.
Be careful with color combinations. Some combinations may be harder for people with low vision to read.
Make sure your text is readable and passes the accessibility guidelines for text contrast. These include text color, background color and text size.
Try to avoid using text over background images, since it’s harder to have enough contrast.
When testing your site, use tools to convert your pages or design into grayscale. Can a sighted user still distinguish the text on the whole site?
Placeholders don’t have enough contrast (and if they had, it would be a bad user experience) so avoid them. At least, don’t use them to communicate crucial info.
This section will concern users who rely on keyboards to navigate websites.
Never set the keyboard focus outline to 0 or none. If you do that, it will become impossible to navigate your website with a keyboard, since the user will have no idea where they are.
The exception could be if you apply specific styles for an element when it’s focused. But it’s hard to keep track of every interactive or focusable element in a page. So make sure you only remove the outline for that specific element.
The default style for the outline is not a good option either since it has low contrast and is very thin. It is highly recommended to set the width to – at least – 3 pixels.
The order of the focusable elements should be logical and intuitive. Try to follow the visual flow of the page.
You shouldn’t change the default keyboard navigation order, do not use tabindex values of 1 or greater.
Links shouldn’t behave like buttons.
If you leave a link element without or with an empty “href” attribute, it won’t become focusable and keyboard users aren’t gonna be able to use them.
If there is some repetitive or boring section your users may want to skip, provide an internal link to the next “interesting” element.
These may fit in none or more than one of the previous sections.
Some users won’t have JavaScript activated. Check if everything makes sense with only HTML and CSS.
If your menu or navbar relies on JavaScript to toggle, leave it open by default so anyone without JS can use it. If there’s JavaScript, you can always close it as soon as the page loads.
Use always relative font sizes! Don’t set your font size with static values like pixels.
Don’t disable zoom on your website so your users can make the text as big or small as they need it.
- Using CSS to enforce Accessibility
- WebAIM Screen reader survey
- WCAG 2.1, Simplified: How to Make Your Website Accessible
- Web Accessibility Initiative: Story of web users
- WebAIm Accessibility checker
- WebAIm Contrast checker
- (Udemy course) WCAG 2.1 / 2.2 Simplified With Examples by Stefany Newman
- WebAIM Screen Reader User Survey 9 results
- Top Five Rules of ARIA