Accessibility: Guidelines and Resources - HOSSTED

Accessibility: Guidelines and Resources

This tutorial covers basic principles of Accessibility, along with important guidelines for the process.

 

An excellent primary resource for Accessibility is: Accessibility Fundamentals with Rob Dodson.

 

The tutorial contains 3 sections:

1. Accessibility: Basic Guidelines

 

2. Important Points Regarding Writing  Accessible Code.

 

3. Resources for Extra Knowledge

 

1. Accessibility: Basic Guidelines
 

The goal of accessibility is to turn a website into accessible pages that a screen reader can read

 

This can be achieved by the following step-by-step process:

 

1.1  HTML from your code is loaded to the browser and creates the page’s structure.

 

1.2  CSS is loaded in order to add design.

 

1.3.  JS is loaded in order to make your page interactive. Here the DOM (document object model) is created.

 

By this stage, the website is ready for the “normative” users.

 

There is a common misconception that this is the end of the processing of your code by the browser, but there is one last step:

 

1.4  The browser creates the “accessibility object model”. This is basically a tree of elements like the DOM, but with extra information that a screen reader needs in order to know what to read to the user. For example: features like the name of the element, element type (button, checkbox, etc.), and important features (button clicked, text area content, etc.).

 
2. Important Points Regarding Writing Accessible Code:
 

2.1 Use native HTML elements. Native HTML elements (button, checkbox, etc., instead of div for everything) have features which help screen readers read correctly whatever is written in the page. This enables you to use an element that behaves with the logic you need. Generic elements will usually add no important information for the screen reader.

 

2.2 WAI-ARIA attributes. These attributes give you the option to add or edit accessibility information of elements. One should use these attributes when the basic HTML element doesn’t provide enough information for the user to understand what is displayed on the screen.

 

Examples of WAI-ARIA attributes:

 

aria-label: names the element

 

aria-required: specifies if the element is required

 

* It is important to remember that ARIA attributes only affect accessibility information and nothing else.

 

Additional Tips:

 

1. Use the accessibility tool inside chrome dev tools in order to see live information about accessibility in a page.

 

2. If you create an element with custom behavior and you want to know what accessibility attributes it needs to have, click on the following link to a website that has many examples of custom elements and the accessibility attributes that they should have:

 

https://www.w3.org/TR/wai-aria-practices-1.1/

 

3. Using aria-labelledby should be the first choice before using aria-label. aria-label should be used only when there’s no text on the screen that correctly describes the specific element. For example: an “X” button should use aria-label.

 

4. Do not skip over headings levels (h1,h2 etc.) Start with h1 and every time there’s a more minor heading, lower the level by one.

 

5. As a rule, screen reader only focuses on interactive elements (buttons, checkboxes etc.). So if you want your screen reader to focus on non-interactive elements, we should use the attribute “tabIndex”.

 

6. There is no need to add aria-label to text elements. Screen readers read their content automatically.

 
3. Resources for Extra Knowledge:
 

3.1  A video explaining all the basic main concepts: Accessibility Fundamentals with Rob Dodson

 

3.2 Playlist of videos explaining many accessibility subjects:

 

Introducing A11ycasts! — A11ycasts #01

 

3.3  Creating accessible forms using Formik:

 

Accessible Formik forms – DEV Community

 
 

Ido Avnir, Linnovate

Skip to content