Information, Semantics & Feedback

A lot of information that is important for interacting with user interfaces (e.g. heading structure) is conveyed via visual cues. Semantic markup makes these accessible to users of assistive technologies such as screen readers.

Probably the most challenging requirements for accessible content to implement are those for ensuring compatibility with complex assistive technologies such as screen reader and voice control software.

In both exemplary cases, all relevant implicit semantic information and properties must be made explicit in order for communication between humans and machines (e.g. screen readers) to succeed.

Regions

Different regions or areas of the user interface, such as banner/header, navigation, main content or footer, must be identified linguistically. Most of the time, these are in fact only recognisable on the basis of visual cues/design features due to conventions.
The same applies to the semantic structure of text content. This mostly concerns heading structure, lists and tables.
Buttons/switches must not be recognisable as such only because of their visual design. The same applies to icons.
Form fields and form field groups must be correctly linked to the respective labels so that it is clear which inputs are expected.

Interactive components (widgets)

The issue of explicit semantic information becomes difficult in connection with scripted interactive elements such as

Modal dialogues / pop-?up windows
(Mega-?) drop-?down menus
Accordions, tab lists and simple drop-?down elements
Carousels
Sliders / slider bars
Tooltips
and many more.

For web content, therefore, the general rule is that native HTML is preferable to scripted interactive components wherever possible. The vast majority of HTML components carry semantic meaning and can be correctly interpreted by screen readers.

The WAI-?ARIA standard of the W3C also allows script-?driven components to be supplemented with semantic information. By means of WAI-?ARIA attributes, role (What is a widget about?), properties (e.g. slider range) and states (e.g. slider position) can be explicated "manually".

Feedback

Especially in interactions, it is extremely important that state changes are always explicitly returned as feedback and not just visually. → ARIA live regions.

Search engine optimizsation (SEO)

Finally, it should be mentioned that search engines benefit enormously from explicit semantic content. Therefore: Accessible content is SEO friendly content.

Semantics test procedure

Regions, landmarks and headings (container)

Examine whether individual areas of a typical view/page are clearly and meaningfully labelled. To do this, we need two extremely valuable tools:
1. external page H123-Bookmarklet : This tool allows a clear presentation of the heading structure of a web page.
2. external page Landmarks Extension, (external page on Github) : This tool provides an overview of the landmarks available on a website (HTML5 landmarks and WAI-ARIA landmark roles).
Check whether the various page areas are properly structured using landmarks and/or headings. This requires some experience.
1. Ideally, the various page regions are labelled using landmarks with additional labels (aria-label, aria-describedby), while headings are used in the (main) content area. Cf. the WAI pages.

Headings (content)

Concentrate on the heading structure in the actual content area; without headers, footers, page columns, navigation areas, etc. To do this, we again use the H123 bookmarklet.

Does the main content start with a heading at H1 level? Are heading levels skipped?
Do the individual headings describe the subsequent content concisely and precisely? Is each heading followed by actual content in the form of text, images, tables or media content?

Lists and tables

The accessibility requirements for lists and data tables demand that these are labelled / tagged in a semantically correct way. The easiest way to check this is to use browser developer tools for source code inspection.

Listings: Is the listing correctly labelled as a list with <ul> or <ol> and <li> elements? Particular attention should be paid to link lists, especially in navigation areas. This is important for screen reader users to know how many items will follow in a list.
Tables: Does the table have table headings <th> in at least one dimension? This is important for screen reader users to be able to access the meaning of the data in a table cell.

Forms

With forms, it is important that form fields are correctly linked to their labels, e.g. by means of for-id linking or nesting (<label>< input ...></label>). When clicking on the label, the keyboard focus must jump to the form field and the cursor should blink there.
Another important requirement for forms is that error messages are linked to the respective form fields, as the labels. This aspect is easiest tested with a screen reader.

Javascript widgets

The semantics of interactive, script-controlled components, known as widgets (like overlays, drop-down elements, or sliders), are tested directly with screen readers. This process involves identifying the type of component, understanding its purpose, and determining its current settings and how to change them.