Achieving Accessibility (A11Y): 11 Key Points for Creating Accessible Websites and Software

 

Imagine if someone handed you a blank piece of paper to read. How would it feel? An inaccessible website or software is just like that blank paper, perhaps with text that isn't printed properly. It’s frustrating and exclusionary.

In my previous articles, I've discussed how making digital products accessible is neither difficult nor expensive. Today, I want to discuss 11 simple tips that can make your website and software accessible to everyone. This is particularly important for developers, startups and entrepreneurs in their early stages, as accessibility should be integrated into planning and development processes right from the start. Think of it like adding ramps to a building—it's much easier to include them in the initial layout.

Page Title

Page <title> is the first thing that screen reader users listen to while navigating the page. Blind users cannot glance quickly at a web page to see what is it about, so they rely on the page title to get that information. Please ensure that the <title> tag is not left empty. Consider following points while providing page title.

·       Page title should be meaningful: A meaningful page title helps users in understanding the purpose of the webpage. It should be short and comprehensive. It is recommended to provide the same page title as the main heading.

Good Example: <title> Students Search Results </title>

Bad Example: <title> Search Results </title>

 

·       Unique information should come first: Keep the page title unique to help users in differentiating various web pages and avoid confusion. Also, unique information should  come first in the page title.

Good Example: <title> Product and Services- Ameiz Vision </title>

In the above example, unique information “Product and Services” is placed first, followed by organization name “Ameiz Vision”.

Bad Example: <title> Ameiz Vision- Product and Services </title>

 

You might be wondering why this matters. Screen readers will read the unique information like ‘Products and Services’ in the end. This require users to spend more time identifying the page's purpose. Web sites that put the brand name first in the title on every page make it hard to distinguish between pages when looking at them in a set of tabs. Screen reader users also find it difficult because they must listen to the same information at the beginning of each page title over and over again, delaying the time it takes to find the page they're on. 

       Besides, a page title also enhances search engine optimization.

 

Language of Page and Parts

Specifying the language of a webpage and its parts is crucial for accessibility because it helps screen readers and other assistive technologies correctly pronounce and understand the content, improve user experience by making multilingual content easier to follow, enhance search engine optimization by ensuring content is properly indexed, and ensure compliance with accessibility standards like WCAG. Using the lang attribute in HTML, you can set the language for the entire page or specific sections, making your website more accessible and user-friendly for everyone.

Landmarks

Although landmarks are not visible on the page, they significantly assist screen reader users in quickly navigating different sections. Typically, screen reader users navigate in a linear fashion, from top to bottom and left to right. However, screen readers offer quick navigation keys for faster access to desired sections or controls. For instance, using the 'D' key with the NVDA screen reader allows users to efficiently move between different regions of the page. Consider the following when providing landmarks:

·       The text should be within the landmark region: This is because landmarks are used to identify various types of content.

·       Label should be programmatically determined when same landmark is used multiple times: This is important for the screen reader users to differentiate between various landmarks on the page. This can be done by using aria-label or aria-labelledby.

·       The number of landmarks should be minimum and appropriate to the content: While there's no technical limit to the number of landmarks on a page, their main purpose is to help blind users quickly find and navigate to the appropriate section. Therefore, keep the total number of landmarks relatively low to avoid overwhelming users with too much information. For instance, marking every list of links as a navigation landmark isn't always necessary. Having one to three well-labeled navigation landmarks is manageable, but having 15 to 20 can make it difficult for users to find the information they need. It is recommended not to have more than 1 banner/header, main and footer/content info landmarks.

 

Headings

Headings are key for making documents accessible and easy to navigate, no matter whether it is a Word file, PDF, or webpage. They help screen reader users move through content and provide a clear structure for all readers. Additionally, in Word documents, properly formatted headings make it simple to generate a table of contents automatically. Consider following things while providing headings.

·       Well-defined Headings: Headings don’t just mean big, bold text. They are defined by heading tags in the code, or by using heading format in the document. Screen readers only recognize headings that are programmatically designated like <h1>, <h2>, <h3>, <h4> etc. This is important because it allows screen reader users to understand the structure of the page and easily navigate to different sections using the 'H' quick navigation key.

 

·       Headings should be precise and accurate: Headings should describe the purpose of the section. When screen reader users pull the list of headings, or when they navigate using quick navigation key on the page, they should be able to understand the purpose of each section. Long headings, or marking complete paragraph as a heading, will be disorienting for the screen reader users.

Good Example: <h2> Classes offered by Ameiz Vision </h2>

Bad Example: <h2> Section 2 </h2>

In the later example, it is observed that the heading is bit generic.

·       Follow proper heading hierarchy: Headings should not miss the hierarchy. They should be in a logical order. Create the structure first and then style the headings as Al screen readers and other assistive technologies pay attention to the structure, not the look and feel. If the default size of the headings is too big for the look you have in mind, use styles to change the size, rather than jumping down to a lower heading level.

       Additionally, headings also enhance search engine optimisation?

Tables

Screen reader users can navigate tables similar to spreadsheets, moving from one cell to another in any direction. If the table's markup is correct, the screen reader will read the table header aloud along with the data in each cell, helping them understand their position within the table.

However, if tables are not marked up properly, screen reader users may struggle to comprehend the data relationships.

Consider the following things while designing a table:

·       Correct Markup: Correct markup is essential for tables because it ensures that screen readers can accurately interpret and convey the structure and content to users with visual impairments. Proper use of HTML elements such as <table>, <thead>, <tbody>, <tr>, <th>, and <td>, along with attributes like scope or headers  allows screen readers to announce the header information alongside the data. This helps users understand the context and relationships between different pieces of data. Without correct markup, the table's information may become confusing or inaccessible, hindering the ability of visually impaired users to effectively interact with the content. Representing tabular data by creating a fake table will lead to the screen reader not considering it as a table.

 

·       Table Caption/Name: When users navigate to a table, screen readers announce the table's caption or name, helping them understand its content. The <caption> element is the simplest way to name a table, but you can also use aria-label or aria-labelledby. On pages with multiple tables, screen reader users can access a list of all tables, displaying each table's caption (like "1st Quarter Results") along with its dimensions (such as "3 columns, 4 rows").

 

·       Layout Tables: Using tables for layout purposes rather than for displaying data is generally discouraged, though it is technically allowed by accessibility guidelines. Tables are semantically designed for organizing data and using them for layout can confuse screen reader users.  Instead, CSS should be used for visual layouts, as it provides a more flexible and robust solution. If a layout table is necessary, adding role="presentation to the <table> element ensures that screen readers treat it as simple text, bypassing the table's semantic structure.

Images

Ensuring the accessibility of images is crucial for creating inclusive digital content. Visually impaired users cannot perceive images just by looking over it. Consider following things if you are including images in your web pages.

·       Alt text: To make images accessible, descriptive alternative text (alt text) should be provided using the alt attribute. This alt text allows screen readers to convey the content and function of the image to users with visual impairments. For decorative images that don't convey important information, an empty alt attribute (alt="") can be used to indicate that the image should be ignored by screen readers. Alt text should not be too long, but it should convey the purpose of the image.

Good Example: <img src=”cat.jpg” alt=”Cat looking outside the window”>

Bad Example: <img src=”cat.jpg”, alt=”cat”>

In the later example, one can observe that alt text is not describing the image clearly.

 

·       Images with Text: Including images that contain text is generally not recommended. Screen readers cannot read text embedded in images, making it inaccessible to visually impaired users. Additionally, users with low vision may struggle to read the text due to formatting issues such as font size, style, or colour.

Audio and Video Content

When creating or incorporating audio and video content on your website, it's crucial to ensure that it is accessible to everyone, regardless of their abilities. In addition to maintaining good sound and video quality, consider the following accessibility features:

·       Captions/Subtitles: Captions are synchronized text versions of spoken dialogue and important sounds in videos. They enable people who are deaf or hard of hearing to follow along with the video content. They also assist users who are in noisy environments or do not understand the spoken language. Create accurate, time-synchronized captions that include all spoken words, sound effects, and speaker identifications. Provide these as closed captions, which users can turn on or off, or as open captions, which are always displayed.

·       Transcripts: Transcripts for videos are comprehensive text versions of both spoken dialogue and visual content. They benefit users who are deaf, hard of hearing, or prefer reading over watching videos. It is also highly beneficial for people who are deaf and blind, as they can read transcripts on braille refreshable display. Transcripts are also useful for quick reference or searching specific content. Develop detailed transcripts that describe all spoken words, significant sounds, and important visual elements. Make these available as downloadable files or embedded in the webpage with the video.

·       Audio Descriptions: Audio descriptions are additional audio tracks that describe key visual elements in a video. They enable visually impaired users to understand what is happening on-screen, providing context that is not conveyed through dialogue alone. Create audio descriptions that narrate actions, scene changes, expressions, and other important visual details. Include these as an optional audio track that users can select if needed.

Links, Buttons and other form controls

Imagine using an AC remote and realizing that the buttons aren’t working or the display is not functioning. How would you feel? Similarly, if links, buttons, or other form controls are not accessible, users with disabilities will be unable to perform the desired actions. Consider following things for making links, buttons and other form controls accessible for everyone:

·       Use semantic markup for user interface components: Sighted users can easily see and identify buttons and links, but screen readers can only convey this information when controls have proper semantic markup, such as <button> for buttons and <input type="text"> for text fields. Elements like <div> or <span> are not recognized as interactive by screen readers. While custom elements may be necessary for aesthetic or other reasons, you can use ARIA roles to help screen readers identify these as interactive elements. However, using semantic markup is highly recommended.

 

·       Provide proper names and labels: Every control must have an associated name or label to clarify its purpose. Ensure that assistive technology recognizes the visual label. Use techniques like aria-label or aria-labelledby to create an "accessible label." If a button has no accessible label, the screen reader will announce it as “button” or “unlabeled button”, providing no hint to users about its purpose. Make sure the visual label matches the accessible label. Otherwise, users of speech input technology won't be able to activate the control. For example, if a visual label is an image with the text "Send" but the accessible label is "Submit", users saying "Send button" won't be able to activate it because their assistive technology recognizes it as a "Submit button”. If you are using proper semantic markups for the labels, then no need to worry for the visual as well as accessible labels.

Managing errors

Imagine trying to fill out a form and when you click 'Submit', nothing happens. No error message. You're left wondering what went wrong. Error messages help users understand what happened, why it happened, and what they can do to correct it. For people with disabilities, especially those using screen readers, clear and accessible error messages are crucial for a positive online experience. Consider following things while showcasing errors:

·       Visible notification in text: Sometimes, errors occur, but the user doesn't know because there's no visible notification in text. Fields with errors might turn red or you'll see a special symbol indicating errors. It is not discouraged to use colours or symbols to show errors but it's also important to include a written message to explain the same. Users who rely on screen readers might miss errors identified only by visual cues, making it difficult for them to understand what's wrong. Additionally, individuals with colour deficiency would struggle to identify errors if only red highlighting is used for fields with errors.

·       Error feedbacks should include suggestions to fix them: Unclear error messages can be confusing. It's important to provide specific details about the problem and suggest a solution. This helps all users, especially users with cognitive disability , to understand and address the issue. Provide suggestions for fixing the errors. For example, if dates are not entered in the correct format, suggest the correct format as well with the error message.

·       Error feedbacks should be announced immediately when it appears on the screen: If error messages are not announced, screen reader users won't know about the issues. Make sure that when there's an error on the screen, it gets announced by a screen reader immediately. To do this, we can use ARIA attributes like role="alert" or aria-live="assertive", on the container where the error message appears. Another way is to make sure the focus goes to the summary of the errors or on the first form element with an error.

·       Error feedbacks should be programmatically associated with the appropriate form elements: Associating error messages with the specific input fields helps users understanding and correcting errors. Screen reader users may encounter difficulty in determining the associated errors for a particular form element while navigating using tab key. This can be solved by using aria-describedby to programmatically associate the error message with the input field.

You can read this article for better understanding Error Feedbacks

 

Reading Order and Focus Order

When screen reader users navigate linearly through content, the order they hear is determined by the order in the Document Object Model (DOM), which is the source code after the browser parses it and runs any relevant JavaScript. While this seems intuitive, there are several issues that need to be consider. CSS positioning techniques (e.g., float, position, margin, padding) can alter the visual layout in ways that don't match the DOM reading order. Additionally, dynamically injected content via JavaScript or AJAX can unexpectedly place elements above the user's current focus, making it difficult for blind users to detect new content without revisiting areas of the page they've already navigated. If the reading order is illogical or unintuitive, the content will not make sense, or it will be difficult to understand for screen reader users.

Similarly, when keyboard users tab through the focusable items (buttons, links, form elements, custom controls, etc.), the order needs to make sense, so they don't get confused. Customizing the tab order with tabindex values like 1, 2, 3, etc., can cause significant problems for keyboard users. It creates a mismatch between the tab order and the reading order, leading to confusion. Items with positive tab index removes them from their natural tab order and instead places them first in the tab order. Also, ensure that focus is visible on the UI component whenever it receive the focus.

 

Colour Contrast

Colour contrast is crucial for accessibility as it ensures that text and essential elements are distinguishable from their background, aiding users with visual impairments such as colour blindness or low vision. Adequate contrast enhances readability and usability, allowing all users to access and comprehend content effectively. According to the Web Content Accessibility Guidelines (WCAG), a minimum contrast ratio of 4.5:1 is required for normal text, and 3:1 for large text, graphs and UI elements, to ensure that information is perceivable and operable by everyone, regardless of their visual abilities.

 

I have covered some points that are important for making your software or website accessible. However, there are other considerations, such as responsive design, carousels, lists, animations, and more. My goal was to keep this article impactful. Thank you for reading through to the end. Your interest in accessibility is commendable, and I encourage your commitment to making websites and software accessible to everyone.

If you would like me to write more about the points not covered here or explore the discussed points in greater detail, please let me know in the comments or email me at amenakanchwala@gmail.com.