Landmark Regions

 

Landmark regions focus on identifying the organization and structure of a web page through the use of sectioning elements in HTML. By classifying and labelling sections of a page, it enables structural information to be conveyed visually for the users.

Screen readers use landmark roles to provide keyboard navigation to important sections of the page. These landmark roles can also be used as targets for skip links.

The general principles of landmark design:

1. Identify the logical structure of the web page by breaking things into perceivable areas of content.
2. Assign landmark roles to each area based on the type of content.
3. Label areas with a unique name if they are used more than once on a page. If a landmark is only used once on a page, it may not require a label.

Specific landmark roles can be found here.

 

 

Names and Descriptions

 

The most important responsibility to an author is understanding the importance of providing accessible names and descriptions where appropriate.

An accessible name is a short string (typically 1 to 3 words) that authors use to associate with an element to provide users with a label for that element. All focusable or interactive elements must have an accessible name. An accessible description is provided when there is a need to provide additional information with an element.

An accessible name serves two primary purposes:

1. Convey the purpose or intent of the element.
2. Distinguish the element from other elements on the page.

The quality of accessible names is one of the most important contributors to usability. Names that don’t provide enough information reduces effectiveness, and names that are too long reduce efficiency. Names that are too difficult reduce both, but also enjoyment.

The Cardinal Rules of Naming can be found here.

 

 

Keyboard Interface

 

For a web page to be fully accessible, all interactive elements must be fully operable via the keyboard. Authors should incorporate common conventions to ensure ease of learning and use of keyboard interfaces.

A primary keyboard navigation convention that is commonly used is “tab” and “shift+tab”. This moves focus from one UI component to another. Other keys, such as the arrow keys, move the focus inside of components that include multiple focusable elements.

The path that the focus follows when pressing the “tab” key is known as the tab sequence. The default order of elements in the tab sequence is the order of elements in the DOM.

When using a keyboard, two essentials for a good experience are the abilities to easily understand the location of the focus, and the ability to discover where the focus landed after a navigation key has been pressed. Three factors that affect these abilities are:

1. Visibility of focus indicator
2. Persistence of focus
3. Predictability of movement

 

 

Grid and Table

 

In order to present or describe a grid or table, assistive technologies must be able to parse headers, rows, and cells using roles described in the grid pattern. They also must be able to determine the following:

• The number of rows and columns.
• Whether any columns or rows are hidden.
• Whether a cell spans across multiple rows or columns.
• Whether and how data is sorted.

ARIA provides properties and descriptions on how to use said properties for grid and table accessibility that can be found here.

 

 

Communicating Values and Limits

 

Authors should be able to communicate a value that is typically numeric and constrained to define its limits. The following widgets can be used to communicate the value.

• Meter
• Progress bar
• Scroll bar
• Separator
• Slider
• Spin button

ARIA provides 4 properties and descriptions on how to use said properties for communicating characteristics of a range widget that can be found here.

 

 

Structural Roles

 

ARIA provides a set of roles that help to convey the accessibility semantics of structures on a given page that show the meaning that is conveyed by the layout and appearance of elements that structure content.

When developing in HTML, it is important to try and avoid using ARIA roles or properties whenever an HTML element with equivalent semantics is available. Instances where it would be appropriate to use ARIA roles instead of HTML equivalents would be:

1. When HTML elements cannot be style in a way that would meet the web pages visual design requirements.
2. When testing reveals that browsers or assistive technologies provide better support for ARIA roles rather than HTML equivalents.
3. When remediating or retrofitting legacy content and altering the underlying DOM to use an HTML equivalent would be cost prohibitive.
4. When building a web component to compose a custom element and the element being extended does not convey appropriate accessibility semantics.

All the structural roles can be found here.

 

Hiding Semantics

 

There are certain situations where hiding an element’s semantics from assistive technologies would be helpful to the users. This is done with the presentation role, which is an element whose semantics will not be mapped. This role declares that an element is only being used for presentation.

There are three common uses of the presentation role:

1. Hiding a decorative image.
2. Suppressing table semantics of tables used for layout in circumstances where the table semantics do not convey meaningful relationships.
3. Eliminating semantics of intervening orphan elements in a structure of a composite widget.

Roles that automatically hide semantics by making descendants elements presentational can be found here.

 

 

Principles

 

Web accessibility is the ability for individuals with a disability to be able to easily access and understand a website, application, or program. It allows them to be a part of the digital world just as much as anyone else.

Certain accessibility principles specific to coding can be found here.