How to Develop for Web Accessibility

Last Edited September 11, 2023 by Garenne Bigby in Accessibility Testing

The international standard for making web content accessible to those with disabilities is called the Web Content Accessibility Guidelines, WCAG for short. These requirements are known as the “success criteria”. Here, you will find some of the most basic considerations that will aid you in getting started with developing content that is accessible to those with disabilities.

Identify the Page Language and Language Changes

You should aim to indicate the primary language of each page by using the lang attribute within the html tag, such as <html lang=”en”> and use this lang attribute for specific elements when the language of the element is not the same as the rest of the page.

Successfully complying with this will make sure that a content developer has provided information within the web page that a user agent needs in order for text and linguistic content to be presented correctly. Conventional user agents and assistive technology will be able to present text more accurately when the language of the page has been identified. Screen readers will be able to load the pronunciation rules, and visual browsers will be presenting scripts and characters correctly. When there are several languages used within a web page, the default text-processing language will be the language that is used the most.

When done correctly, this will help those who use technologies like a screen reader to convert text into synthetic speech. It will also aid those who have difficulties reading written material fluently and accurately—due to language, learning, or cognitive disabilities. Additionally, those who rely on captions for interpreting synchronized media will reap the benefits of clear language identification.

Associate a Label on Every Form of Control

You should aim to use a “for” attribute on the <label> element that is linked to the id attribute in the form element, or you can use WAI-ARIA attributes. In some certain scenarios, it would be necessary to visually hide the <label> elements, but for the most part, case labels are indeed needed to help the reader to understand all of the required input.

When done successfully, the content authors will have placed labels or instructions that denote the controls in a form so users will know exactly what input data is expected. These labels will also indicate data formats for fields, particularly when they are not in the normal format or if there is a specific set of rules for the form. It is also possible for the content author to make a set of instructions available to those individuals with disabilities when the instructions are longer than normal and tedious. The intent is not to clutter the page with unneeded information, but provide vital cues and instructions that will be beneficial to those who have disabilities. Too little instruction can be just as hindering as too much instruction.

Clear labels and instructions are beneficial in many ways. When associated with input elements, they can be spoken by a screen reader when that field is in focus, and users that have impaired motor skills benefit from a larger clickable area, since the label will activate the control. When examples of expected data formats are given, users with language, cognitive, and learning disabilities are able to give information in the correct way. When required fields are clearly identified, those who use only a keyboard will be able to navigate the form and provide all of the information that is needed.

Utilize the ALT Text for Images

You should be making sure that the alternative text used for images is added to every functional and informational image. You may use an empty alternative text tag like alt=”” for images that are decorative, or you may opt to include them in the CSS. Text alternatives are generally provided by those who are responsible for the written content.

The intent of this when done successfully is to allow information conveyed by non-text content to be accessible through the use of a text alternative. Primarily, text alternatives are used to make information accessible because they can then be furnished through other sensory modalities, like auditory, visual, or tactile in order to match the needs of the individual.

Thinking of this success in a more specific way, text alternatives are beneficial to those who struggle with perceiving visual content—they may use assistive technology to read text out loud, convert it to braille, or have it presented visually. These alternatives may also help those who have a hard time interpreting the meaning of media like images, drawings, or photographs. Text presentations aid those who are hard of hearing or have difficulties understanding audio information.

Avoid and Correct User Mistakes

Aim to give clear instructions, notifications, and error messages in order to help the users to complete the forms on your website. When an error does occur, you should be able to provide understandable explanations, suggest corrections, and help the user to find out where the problem is. The format should be as forgiving as possible when processing their input, for instance aim to accept phone numbers that include spaces, but delete spaces when needed.

Ideally, this will make sure that a user will be aware that an error has occurred, and they will be able to tell what went wrong so that they can correct the error. The error message needs to be as specific as possible, whether it is indicating an unsuccessful form submission, or anything of that nature. You should aim to indicate the fields in which an error occurred in a way that the user can perceive it. Those who use screen readers will not be able to see that there was an error until the screen reader encounters the indicator. It is possible that they will abandon the page if they think that the form simply is not working. The identification and description of the error may be combined with programmatic information that user agents or assistive technology will use to identify the error and then provide the necessary information to the user.

When used successfully, it will help those who have learning, cognitive, and language disabilities to understand the meaning of the icons and other visuals. It will also give information about input errors within the text will allow users that are blind (or colorblind) to observe the reaction of the error.

The Code Order Should Reflect the Reading Order

Be sure that the order of the elements within the code is a match to the logical order of the information that is presented. You can check this by removing the CSS styling and then review that the order of the content will make sense.

The intent for this criteria is to be able to provide a user agent with an alternative representation of the content while still preserving the reading order that is needed so that the meaning is understood. It is important to ensure the possibility to program at least one sequence that makes sense for the content.

When done correctly, this will help users who rely on assistive technology that reads content out loud. The meaning of the content in the default presentation needs to be the same when the content is presented in spoken form.

Convey Meaning and Structure with Markup

Use the appropriate markup for all headings, tables, lists, and elements like that. HTML5 will provide more elements like <aside> and <nav>, in order to structure the content in a better way. The WAI_ARIA roles will be able to give additional meaning, like role=”search” that would identify a search functionality. If you are not familiar with this aspect, you should work with content writers and designers so that you will have consistent meanings throughout the content.

The reason for these guidelines is to make sure that the information as well as relationships that are implied by auditory or visual formatting are saved when the format of the presentation changes. Sighted users are able to understand structure and relationships through visual cues—headings are large and bold, list items are bulleted or numbered, form fields are in groups, and so on. When these structures and relationships are determined through programming or available in text asserts that the information that is important for comprehending the data will be able to be understood by all. Auditory cues can be implemented as well—a change in voice pitch or rate of speech could emphasize important text, and things like that.

When implemented successfully, users with various disabilities will be able to adapt the content to their own needs and will gain access to the valuable information.

Non-standard Interactive Elements Should be Given Meaning

Employ WAI-ARIA in order to provide information on the function and state for a custom widget, like a custom button. For instance, role=”navigation” and aria-expanded=”true”. More code is required to apply the behavior of these types of widgets, like expanding or collapsing content, or how the keyboard controls a widget.

All interface components should be provided with state, role, and value information so that they are compatible with all assistive technologies.

Avoid the Use of CAPTCHA When Possible

Interestingly, CAPTCHAs create problems for a significant amount of individuals. There are several other means of verifying user input being put in by a person that are simpler to use like an automatic detection and interface interaction. If it is absolutely necessary for CAPTCHA to be used, make sure that it is fairly simple to understand and does include an alternative to individuals with disabilities. This can be done by not requiring a CAPTCHA for users that are authorized, providing access to an actual person in customer service who is able to bypass the CAPTCHA, or provide more than just two ways to solve the CAPTCHA.

Interactive Elements Should be Keyboard Accessible

Determine the keyboard accessibility when designing interactive elements like media players, menus, collapsible elements, and mouse over information. You will use tabindex=”0” in order to add an element that would not normally receive focus, like <span> or <div>, into the navigational order when being used for interaction. You should use scripting to capture and respond to events triggered by a keyboard.

This will ensure that content may be operated through the use of a keyboard or keyboard interface, this allows content to be operated by people with no vision, or those who use alternate keyboards. Many actions that are performed with a pointing device may also be done with a keyboard, but there is a small fraction of actions that is done only with a pointing device. It should be noted that the designer of user input should be taking into account that some users will rely on a website having keyboard accessibility features

When done correctly, those who have low vision, those who are blind, or those who have difficulties using a mouse will be able to successfully navigate a website and use the content contained within. The content should still function in the way that it was intended in the accessible environment, and will not interfere with any of the assistive functions when displaying content. For example, a drawing program should still allow users to size, rotate, position, and draw objects using the keyboard.

The Code Should Be Written to Adapt to the User's Technology

Utilize responsive design that will help the display to adapt to different zoom states as well as viewport sizes—like mobile devices and tablets. When a font size is increased by more than 200%, do not use horizontal scrolling and prevent content from being clipped. Employ progressive enhancement to aid in making sure that the core functionality and content is accessible regardless of what technology is being used to access it.

In short, this ensures that text can be scaled either up or down to be able to be read by those with mild visual disabilities, without using assistive technology. All content on the page should be able to scale, but text is the most important. Successful use of this will allow the content to be scaled up to 200%, but beyond that is acceptable as well.

Author: Garenne BigbyWebsite: http://garennebigby.com

Founder of DYNO Mapper and Former Advisory Committee Representative at the W3C.

Back

Create Visual Sitemaps

Create, edit, customize, and share visual sitemaps integrated with Google Analytics for easy discovery, planning, and collaboration.

Popular Tags

Search Engine Optimization SEO Accessibility Testing Create Sitemaps Sitemaps UX User Experience Sitemap Generator Content Audit Visual Sitemap Generator