As we continue our journey toward becoming certified Trusted Testers, this session reinforced that accessibility is just as much about creating a predictable, logical, and efficient experience for everyone.
Topic 9: Repetitive Content
‘Repetitive Content’ means parts which are the same across multiple pages of a website. We want to ensure that users can bypass repeated blocks and navigate consistently across the same website.
9.A. Bypass Function (WCAG 2.4.1)
The goal is to allow users to jump straight to the main content, without having to plow through the same thing over and over. Instead, what we want is a keyboard-accessible mechanism that allows us to skip over blocks of content repeated on multiple pages, e.g. navigation, footer, or sidebar. “Skip to Main Content” links are the most well-known mechanisms for this, but other bypass methods like hotkeys or scripted elements also exist.
This test does not apply to single-page sites (like a standalone survey) or sites where repeated content is limited to small sections, e.g. single words or individual links.
9.B. Consistent Navigation (WCAG 3.2.3)
Consistency is key, not only in skincare. If a user learns the layout of one page, they should be able to expect the same layout on the next.
Navigational mechanisms repeated across pages must occur in the same relative order. The exact text of the links can change (e.g., “Next Page” vs. “Continue”), but the order of the navigation elements relative to each other must remain constant.
How to test: Compare the Reading Order and Tab Order across pages using ANDI to ensure the sequence of elements (e.g., Logo -> Search -> Menu -> Footer) to check if they remain consistent.
9.C. Consistent Identification (WCAG 3.2.4)
This criterion ensures that components performing the same function are identified consistently across the site. Users rely on consistent naming to build mental models of the site. If a search icon is labeled “Search” on the homepage but “Find” or “Locate” on internal pages, it fails.
Function Over Form: An “X” icon might mean “Delete” on one page and “Deny” on another. This is acceptable only if the accessible name (text alternative) reflects the specific function (e.g., “Delete Document” vs. “Deny Request”).
Topic 10: Content Structure
The second half of the session shifted to how content is organized. Assistive technologies rely on code to understand the page hierarchy, not just visual styling.
10.A. Heading Purpose (WCAG 2.4.6)
Headings must describe the topic or purpose of the content that follows them. This requires a manual inspection - or rather: simply using your brain - to compare the heading text against the content following it.
Our fail example was a shoe store page with a heading “Flat Shoes” but then followed by text describing stilettos and pumps, the complete opposite of what the heading references. The heading must accurately reflect the content. This test does not apply if a page has no visual headings, e.g., a simple news article with only body text.
10.B. Determinable Heading (WCAG 1.3.1)
This is a “two-way street” test:
- Every visual heading must be programmatically defined as a heading (
<h1>–<h6>). - Every programmatically defined heading must also be a visual heading.
It still happens far too often that people style text to look like a heading without using the proper HTML heading tags, or the opposite: use heading tags for emphasis.
10.C. Heading Level (also WCAG 1.3.1)
The hierarchy of headings must logically match the visual presentation. If a section is visually the most important, it should have the highest priority level (e.g., <h1>).
Be aware that testing and development differ here: While best practice suggests sequential levels h1 -> h2 -> h3 (with the h1 ideally also matching the URL slug), the Trusted Tester process actually allows skipping levels, if the visual structure supports it. However, the programmatic level must still make sense in context. If there is a conflict between HTML and ARIA-labels, ARIA takes precedence.
Even if it doesn’t impact Trusted Tester conformance, I would still suggest making a note of skipped heading levels in your test report.
10.D. Lists (again WCAG 1.3.1)
Another test criterion of the “if it looks like a thing, it should also be that thing” type: Visually apparent lists must be coded as lists (<ul>, <ol>, or <dl>). A numbered list created using CSS counters or just typing “1.”, “2.”, “3.” is not apparent to assistive technology. Proper list tags are:
-
<ul>Unordered Lists: These are typically bullet point lists (like this one!), where the order of the list items doesn’t matter. -
<ol>Ordered Lists: Typically rendered as a numbered list, but you also probably have seen them starting with a) or i) before. -
<dl>Description Lists: Less often seen than the two above, these lists enclose a list of groups of terms and descriptions. Think of a glossary listing multiple terms and their definitions.
Notable exception: Navigational menus that happen to be coded as lists but are part of the navigation framework (not main content) are excluded from this specific test.
Materials
- Join the next session: GDG Vienna
- Study Group recordings playlist on YouTube
- Session slides and transcripts on Google Drive
- GitHub repository
- Summaries on A11y News
- Previous GDG Vienna Accessibility Webinar Series
- WebAIM Million Report
- DHS Section 508 Coordinators: Quick Reference with Test Conditions