The Web Content Accessibility Guidelines (WCAG) contains simple guidance for building websites, mobile apps, and other digital content that works for everyone. However, some WCAG terminology can cause confusion — particularly for web developers who have limited experience with the language of accessibility.
Eight criteria in WCAG 2.1 require content to have “programmatically determinable” names, roles, and relationships. If you’re confused, don’t worry; here’s a quick guide to what “programmatically determined" means (and why it’s an important concept to keep in mind).
What “Programmatically Determined" Means
Websites need a semantic structure that defines the purpose of different elements and the relationships between those elements. When this structure can be understood through a page’s markup, it can be programmatically determined.
For example, a subheading tag breaks content into smaller sections and explains what the reader can expect from each section. On this page, What “Programmatically Determined" Means is the first subheading. If you’re looking for a quick definition, you know that you can read this section of the content to find the information you need.
People who perceive content visually can look through this blog and find the subheadings easily. However, many internet users don’t process information visually.
Some of these people use screen readers (which convert text to audio or braille output) or other assistive technologies. Without semantic structure, these users may not be able to find subheadings, navigation links, or other important elements without reading the entire webpage.
For a website to work as intended — regardless of how a user accesses it — it needs appropriate markup. The markup is usually HTML, though WAI-ARIA (Web Accessibility Initiative - Accessible Rich Applications) is sometimes necessary.
Related: How Headings Help People with Disabilities Navigate a Website
The Benefits of Semantic Markup
If the site has accurate markup, the purpose of each element can be identified by software (or programmatically determined).
This simple concept has enormous benefits. In addition to providing an important accommodation for screen readers, content that has appropriate markup is easier to browse with a keyboard alone (no mouse). It’s easier to use with eye-tracking software, speech recognition software, and other assistive technologies. People can change the presentation of the content into different formats without losing information.
In short, when semantics can be programmatically determined, your website is more robust. It will work with a wider variety of technologies, and you’ll provide your users with a much better experience.
Related: What Are the Four Major Categories of Accessibility?
Improving Accessibility with Semantic Markup
Developers have two primary tools for defining semantics: HTML and WAI-ARIA. Generally, HTML is the better choice; it enjoys wide support, and most elements can be defined with HTML alone.
Providing Semantic Information with HTML
Structural HTML can improve accessibility by identifying most common elements and relationships including:
-
- The language of the page
- Tables, lists, and figures
- Headers and footers
- Subheadings
- Hyperlinks
- Marked or highlighted text
- Image captions
When writing markup, remember that HTML should be structural, not presentational. Use HTML to define structure, then use CSS or other technologies to style the visual presentation.
Related: Plain Old Semantic HTML: A Perfect Basis for Accessibility.
Providing Semantic Information with WAI-ARIA
WAI-ARIA (also referred to as ARIA) is a defined technical specification that identifies structures and relationships for assistive technologies. The first rule of ARIA is to use HTML instead — but some types of complex or dynamic content cannot be defined with HTML alone.
In these situations, WAI-ARIA can provide attributes for HTML elements, including progress bars, status messages, toolbars, and elements within web applications. ARIA can also hide unnecessary content from assistive technologies or deliver additional information that isn’t available visually. It’s a powerful tool, but improper ARIA markup can cause new accessibility issues.
If you decide to use ARIA, we strongly recommend reviewing our introduction to ARIA and the official WAI-ARIA overview page from the World Wide Web Consortium (W3C).
Related: 4 Questions to Ask Before Using ARIA
Semantics are crucial for accessibility compliance
WCAG 2.1 Success Criterion 1.3.1, “Info and Relationships,” requires that all “information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.” Content that fails to pass this guideline cannot be considered reasonably accessible.
While WCAG conformance is voluntary, most websites have a legal responsibility to accommodate all users. Litigation filed under Titles II and III of the Americans with Disabilities Act (ADA) frequently references WCAG standards, and the Department of Justice has identified WCAG as a reasonable standard for ADA compliance. Outside of the United States, many international web accessibility laws use WCAG as a framework.
Of course, proper markup has dozens of benefits apart from legal compliance. By using HTML and ARIA correctly, you’ll have a more robust website with cleaner code — that generally means lower long-term maintenance costs. Your content will work more effectively on all platforms, and you’ll enjoy better search engine positioning.
For more guidance, download the Bureau of Internet Accessibility’s Ultimate Guide to Web Accessibility.
