diff --git a/src/config/2025.json b/src/config/2025.json
index cd09a3f6298..8133238303b 100644
--- a/src/config/2025.json
+++ b/src/config/2025.json
@@ -81,8 +81,7 @@
"part": "II",
"chapter_number": "9",
"title": "Accessibility",
- "slug": "accessibility",
- "todo": true
+ "slug": "accessibility"
},
{
"part": "II",
diff --git a/src/config/contributors.json b/src/config/contributors.json
index 6634845e89d..302967136be 100644
--- a/src/config/contributors.json
+++ b/src/config/contributors.json
@@ -74,16 +74,6 @@
]
}
},
- "onurguler18": {
- "avatar_url": "39603688",
- "github": "onurguler18",
- "name": "Onur Güler",
- "teams": {
- "2024": [
- "analysts"
- ]
- }
- },
"argyleink": {
"avatar_url": "1134620",
"github": "argyleink",
@@ -170,6 +160,18 @@
"twitter": "MrAhmadAwais",
"website": "https://AhmadAwais.com"
},
+ "atierney": {
+ "avatar_url": "9468139",
+ "name": "Aidan Tierney",
+ "github": "AidanA11y",
+ "linkedin": "aidantierney",
+ "bluesky": "aidantierney.bsky.social",
+ "teams": {
+ "2025": [
+ "reviewers"
+ ]
+ }
+ },
"akshay-ranganath": {
"avatar_url": "54864775",
"github": "akshay-ranganath",
@@ -692,7 +694,8 @@
],
"2025": [
"committee",
- "developers"
+ "developers",
+ "analysts"
]
},
"twitter": "tunetheweb",
@@ -781,6 +784,20 @@
},
"website": "https://iambharat.me"
},
+ "tricinel": {
+ "avatar_url": "216008",
+ "name": "Bogdan Lazar",
+ "github": "tricinel",
+ "bluesky": "bogdanlazar.com",
+ "linkedin": "tricinel",
+ "website": "https://bogdanlazar.com",
+ "teams": {
+ "2025": [
+ "authors",
+ "editors"
+ ]
+ }
+ },
"borisschapira": {
"avatar_url": "284742",
"github": "borisschapira",
@@ -1906,6 +1923,9 @@
"teams": {
"2024": [
"reviewers"
+ ],
+ "2025": [
+ "reviewers"
]
},
"mastodon": "https://front-end.social/@hdv",
@@ -3230,6 +3250,10 @@
"2024": [
"analysts",
"authors"
+ ],
+ "2025": [
+ "authors",
+ "analysts"
]
},
"website": "https://accessibility.civicactions.com/"
@@ -3568,6 +3592,16 @@
"twitter": "oluoluoxenfree",
"website": "https://olu.online/"
},
+ "onurguler18": {
+ "avatar_url": "39603688",
+ "github": "onurguler18",
+ "name": "Onur Güler",
+ "teams": {
+ "2024": [
+ "analysts"
+ ]
+ }
+ },
"pankajparkar": {
"avatar_url": "5320044",
"github": "pankajparkar",
@@ -4233,6 +4267,9 @@
],
"2022": [
"authors"
+ ],
+ "2025": [
+ "reviewers"
]
},
"twitter": "scottdavis99",
diff --git a/src/content/en/2025/accessibility.md b/src/content/en/2025/accessibility.md
index f0c715cca58..153a6f32373 100644
--- a/src/content/en/2025/accessibility.md
+++ b/src/content/en/2025/accessibility.md
@@ -3,18 +3,1187 @@
title: Accessibility
description: Accessibility chapter of the 2025 Web Almanac covering ease of reading, navigation, forms, media, ARIA, and accessibility apps.
hero_alt: Hero image of a robot with a blue, human accessibility icon on its front scanning a web page, while Web Almanac characters check some labels.
-authors: []
-reviewers: []
-analysts: []
-editors: []
+authors: [tricinel, mgifford]
+reviewers: [hidde, atierney, scottdavis99]
+analysts: [mgifford, tunetheweb]
+editors: [tricinel]
translators: []
-results: https://docs.google.com/spreadsheets/d/13sY_wmYODArxo-hH5cSuRAbvtLdGI3x5Xc9qUyqP8as/edit
-featured_quote: ...
-featured_stat_1: ...
-featured_stat_label_1: ...
-featured_stat_2: ...
-featured_stat_label_2: ...
-featured_stat_3: ...
-featured_stat_label_3: ...
-doi: ...
+tricinel_bio: Bogdan is the accessibility consultant who helps product owners ship accessible websites without blocking ongoing work. He brings over a decade of experience in education and healthcare, with deep expertise in inclusive design and web accessibility. He's been writing a daily newsletter on accessibility since March 2024, driven by one core belief. "Make room for everyone."
+mgifford_bio: Mike Gifford is CivicActions' Open Standards & Practices Lead. He is also a thought leader on open government, digital accessibility and sustainability. He has served as a Drupal Core Accessibility Maintainer and also a W3C Invited Expert. He is a recognized authoring tool accessibility expert and contributor to the W3C's Draft Web Sustainability Guidelines (WSG) 1.0.
+results: https://docs.google.com/spreadsheets/d/13sY_wmYODArxo-hH5cSuRAbvtLdGI3x5Xc9qUyqP8as/
+featured_quote: The web should work for everyone. Until that principle guides our decisions, accessibility gaps will persist.
+featured_stat_1: 85
+featured_stat_label_1: Median Lighthouse accessibility score.
+featured_stat_2: 67%
+featured_stat_label_2: Sites removing default focus outlines.
+featured_stat_3: 2%
+featured_stat_label_3: Sites using accessibility overlays.
---
+
+## Introduction
+
+The web is changing fast. In 2025, web accessibility matters more than ever as mainstream technologies increasingly rely on inclusive features. For example, voice-activated assistants use screen reader technologies. Features originally designed for accessibility, such as video captions and haptic feedback, are now common.
+
+Universal Design principles are fundamentally important for our work in modern web development. We're increasingly creating solutions that address diverse needs and improve experiences for all users. As Sir Tim Berners-Lee famously said, "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect."
+
+Recent global events and shifting legal requirements have pushed digital inclusion into focus. Microsoft's Inclusive Design Guidelines show that accessibility helps more than just people with permanent disabilities. The guidelines specifically mention temporary and situational limitations. For example, the ability to use a device with one hand can help individuals with injuries, parents with young children, as well as people carrying items.
+
+In 2025, web accessibility laws have real teeth. The European Union's (EU) [European Accessibility Act (EAA)](https://en.wikipedia.org/wiki/European_Accessibility_Act) is a major step forward. It set a deadline of June 2025 for numerous websites and apps to conform to the [EN 301 549](https://en.wikipedia.org/wiki/EN_301_549) standard, which references the Web Content Accessibility Guidelines (WCAG).
+
+The United States updated its regulations as well. State and local government sites must now meet WCAG 2.1, as required by Title II of the Americans with Disabilities Act. The 2024 data gives us a critical baseline to measure the tangible impact of these deadlines on the accessibility of websites globally.
+
+Google Lighthouse powers our analysis using Deque's axe-core engine. We benchmark 2025 findings against 2024 data and identify key trends. With broader adoption of WCAG 2.2, we examine the uptake of new Success Criteria and continued changes from deprecated rules such as `duplicate-id`.
+
+Our approach is similar to that of the WebAim Million but with differences in sites crawled and analysis tools used. The HTTP Archive crawls 17 million sites each month across home and secondary pages using Lighthouse and other tools. WebAim surveys the top million home pages with WAVE.
+
+Automated tests, including axe-core which is used by Lighthouse, can only partially check a subset of WCAG Success Criteria. Alphagov from GOV.UK offers a comparison of popular automated audit tools and they all detect less than 50% of accessibility errors. Many criteria lack automated tests altogether, and not all accessibility issues have matching criteria in WCAG.
+
+But remember Goodhart's Law. When a metric becomes a target, it stops being a reliable metric. A perfect score doesn't guarantee full accessibility. You should treat Lighthouse accessibility scores as a starting point for evaluation rather than a final goal. Still, tracking these scores offers a valuable snapshot of the web's overall progress.
+
+Our report focuses exclusively on HTML and doesn't include PDF or other office documents.
+
+Compared to 2024, the median Lighthouse Accessibility score improved by 1%, reaching over 85% in 2025. Since the first Web Almanac in 2019, we've seen steady and incremental progress. Google Lighthouse assigns different weights to axe-core issues, so organizations may prioritize fixes differently.
+
+{{ figure_markup(
+ image="lighthouse-audit-improvements-yoy.png",
+ caption="Lighthouse audit improvements year-over-year.",
+ description="A bar chart showing the average increase in the media Google Lighthouse accessibility score over time for six years. Values increase slowly year by year, as follows: in 2019 83%, in 2020 80%, in 2021 82%, in 2022 83%, in 2024 84%, and in 2025 85%.",
+ chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQFD-7C6Jv6q1JyviDsKosRlVwaok7g7nRCQ9NGMw5MaAAohL7EcDejVwgp13Z_T2S_57Zi0YaVb7st/pubchart?oid=1116937150&format=interactive",
+ sheets_gid="1543303999",
+ sql_file="lighthouse_a11y_score.sql"
+ )
+}}
+
+This year, we've seen the biggest advances in the following axe-core tests:
+
+- ARIA input fields must have an accessible name: +3% over 2024
+- ARIA `meter` nodes must have an accessible name: +15% over 2024
+- ARIA `progressbar` nodes must have an accessible name: +5% over 2024
+- ARIA `tooltip` nodes must have an accessible name: +13% over 2024
+- Avoid delayed refresh under 20 hours: +1% over 2024
+- `: +1% over 2024
+- `: +5% over 2024
+
+{{ figure_markup(
+ image="most-improved-lighthouse-accessibility-tests-axe.png",
+ caption="Most improved Lighthouse accessibility tests (axe).",
+ description="A series chart showing the improvements on seven specific Lighthouse checks over time for four years. For `aria-input-field-name`, in 2021 12%, in 2022 14%, in 2024 21%, and in 2025 24%. For `aria-meter-name`, in 2021 0%, in 2022 100%, in 2024 35%, and in 2025 50%. For `aria-progressbar-name`, in 2021 1%, in 2022 3%, in 2024 14%, and in 2025 19%. For `aria-tooltip-name`, in 2021 29%, in 2022 75%, in 2024 74%, and in 2025 87%. For `meta-refresh`, in 2021 and 2022 2%, in 2024 7%, and in 2025 8%. For `object-alt`, in 2021 1%, in 2022 20%, in 2024 10%, and in 2025 11%. For `select-name`, in 2024 37%, and in 2025 42%.",
+ chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQFD-7C6Jv6q1JyviDsKosRlVwaok7g7nRCQ9NGMw5MaAAohL7EcDejVwgp13Z_T2S_57Zi0YaVb7st/pubchart?oid=2072636024&format=interactive",
+ sheets_gid="1312474493",
+ sql_file="lighthouse_a11y_audits.sql"
+ )
+}}
+
+This year, we're adding a new section on [Artificial Intelligence (AI)](#the-impact-of-artificial-intelligence-ai) to the Web Almanac. AI is changing how we build websites, write code, generate content, optimize performance, and interact with interfaces. It already plays a growing role in accessibility work, from generating image descriptions and captions to assistants that help teams find and fix issues.
+
+At the same time, AI introduces risks and unanswered questions. There's no reliable way yet to see when AI has created or assisted in creating a website. Language models are trained on code and content that often contain accessibility problems. Automated descriptions or patterns can easily miss context, user intent, or nuance. Broader concerns about data use, environmental impact, and encoded bias directly affect who benefits from AI on the web and who is harmed or excluded.
+
+The new AI chapter explores these tensions: how AI is already helping teams, where it falls short, and what standards, safeguards, and practices are needed. One principle runs through the analysis: AI should support human expertise and inclusive design, not replace them.
+
+Throughout this chapter, you will find actionable links and practical solutions to help you improve accessibility on your own sites.
+
+## Ease of reading
+
+Users need to easily read and understand web content. This goes beyond picking legible fonts. It also covers using clear language, organizing pages logically, and following predictable design patterns.
+
+While this report focuses on measurable technical metrics, qualitative factors, such as writing in plain language, matter just as much. WCAG 3.0 is exploring how to incorporate requirements for clear language, but it's still in the development phase.
+
+Similar to plain language, numbers pose their own accessibility challenges. Some users struggle to interpret them, and automated tests can't reliably catch this as a barrier. To address this, review resources like Accessible Numbers for practical advice on presenting numeric information clearly on the web.
+
+Readability metrics exist for English content. The [Flesch-Kincaid](https://en.wikipedia.org/wiki/Flesch%E2%80%93Kincaid_readability_tests) readability score is one example. But the web is global. It spans many languages and diverse audiences. No standardized automated test covers all cases or languages.
+
+### Color contrast
+
+The difference between foreground and background colors determines whether people can perceive web content. Insufficient color contrast remains a common barrier, especially for users with low vision or color vision deficiencies.
+
+Color contrast is especially important for older users, people with temporary disabilities, like missing reading glasses, and anyone reading under bright sunlight or in challenging environments.
+
+WCAG requires contrast ratios of at least 4.5:1 for standard text and 3:1 for large text to achieve AA conformance. AAA conformance demands 7:1 for normal text. [WCAG contrast ratios](https://developer.mozilla.org/en-US/docs/Web/Accessibility/Guides/Understanding_WCAG/Perceivable/Color_contrast) are an important baseline, but these guidelines don't address every form of color blindness or individual variation in perception.
+
+Other documents, including the Accessible Perceptual Contrast Algorithm (APCA), aim to offer a more perceptually accurate measurement of contrast.
+
+Open source tools, like the newly released Contrast Report, make it easier than ever to find and fix color contrast issues. They even suggest modifications when colors fail to meet required ratios. For additional guidance, you can consult expert resources, such as Dennis Deacon's article on color contrast testing.
+
+{{ figure_markup(
+ image="sites-with-sufficient-color-contrast.png",
+ caption="Sites with sufficient color contrast.",
+ description="A series bar chart showing the percentage of website with sufficient color contrast across six years, on both desktop and mobile. In 2019 22% had sufficient color contrast. In 2020, it dropped to 21%, and recovered in 2021 to 22%. In 2022 on desktop and mobile it was 23%, and in 2024 it shot up on desktop to 28% and on mobile to 29%. In 2025 on both desktop and mobile it is 30%.",
+ chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQFD-7C6Jv6q1JyviDsKosRlVwaok7g7nRCQ9NGMw5MaAAohL7EcDejVwgp13Z_T2S_57Zi0YaVb7st/pubchart?oid=1491798527&format=interactive",
+ sheets_gid="15996962",
+ sql_file="color_contrast.sql"
+ )
+}}
+
+This year, text contrast pass rate improved by roughly 1% compared to 2024. But only 31% of mobile sites currently meet minimum color contrast requirements. Since mobile experiences depend heavily on clear visibility, this gap is a real problem for users accessing the web on their phones.
+
+Browsers and operating systems increasingly support light, dark, and high-contrast modes. Users have more control now. Most sites still don't respond to these preferences though.
+
+### Zooming and scaling
+
+Users must be able to resize content to suit their needs. Disabling zoom removes user control and is a direct violation of WCAG resizing requirements. This is more than a minor inconvenience. It may make a site completely unusable for people with low vision or those who rely on screen magnification for reading.
+
+In 2025, this restrictive pattern still appears, often because developers want pixel-perfect layouts on mobile devices. Unfortunately, that comes at the cost of usability and accessibility.
+
+{{ figure_markup(
+ image="pages-with-zooming-and-scaling-disabled.png",
+ caption="Pages with zooming and scaling disabled.",
+ description="A series of bar charts showing data on disabled zooming for desktop and mobile. 15% of desktop sites and 13% of mobile sites disable scaling, 19% and 17% respectively set a max scale of 1 and 21% and 19% use either.",
+ chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQFD-7C6Jv6q1JyviDsKosRlVwaok7g7nRCQ9NGMw5MaAAohL7EcDejVwgp13Z_T2S_57Zi0YaVb7st/pubchart?oid=327558014&format=interactive",
+ sheets_gid="684000055",
+ sql_file="viewport_zoom_scale.sql"
+ )
+}}
+
+The number of sites that disable zooming or scaling continues to drop. In 2025, only 19% of mobile sites and 21% of desktop sites restrict scaling, either by using `user-scalable=no` or setting a restrictive maximum scale. That's a 1–2% improvement over 2024, showing slow but steady progress.
+
+{{ figure_markup(
+ image="font-unit-usage.png",
+ caption="Font unit usage.",
+ description="A bar chart showing `px` is used for font sizes on 67% of desktop, `em` on 16%, `rem` on 9%, percentages on 4%, `` on 2%, and finally `pt` on 1% of websites tested.",
+ chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQFD-7C6Jv6q1JyviDsKosRlVwaok7g7nRCQ9NGMw5MaAAohL7EcDejVwgp13Z_T2S_57Zi0YaVb7st/pubchart?oid=611369037&format=interactive",
+ sheets_gid="1493373752",
+ sql_file="units_properties.sql"
+ )
+}}
+
+Font size units directly affect how text can respond to user preferences. Relative units, such as `em` and `rem`, let text to scale predictably with browser settings. In 2025, the use of `em` on mobile sites increased by 2%, improving user experiences for those who adjust font sizes to increase readability. Otherwise, font size unit usage stays largely the same as last year.
+
+If you want to check whether your site is restricting zoom, examine its source code for the `` tag. Avoid using values like `maximum-scale`, `minimum-scale`, `user-scalable=no`, or `user-scalable=0`, as these limit resizing. Instead, let users freely adjust content size. WCAG requires that text can resize up to 200% without loss of content or functionality.
+
+### Language identification
+
+Declaring a page's primary language with the `lang` attribute is essential. It lets screen readers select the correct pronunciation rules and enables browsers to provide more accurate automatic translations. Beyond the primary language, it’s equally important to specify the language of sections that differ from the main language. This ensures that screen readers properly switch pronunciation for foreign words or phrases.
+
+Despite being a straightforward Level A WCAG requirement, language declaration remains an area where many sites fall short. In 2025, roughly 86% of sites include a valid `lang` attribute, largely unchanged from 2024. This suggests steady adoption but also highlights room for improvement.
+
+Correctly applying the `lang` attribute begins with including it on the `` tag to specify the page's primary language. Pages often contain multiple languages. Use the `lang` attribute on individual elements or sections as needed. The W3C’s documentation on specifying the language of parts provides detailed guidance on this topic.
+
+Missing or incorrect language declarations can cause translation errors.
+
+For example, Chrome's automatic translation might misinterpret page content without a declared language, leading to confusing or inaccurate translations. Proper language tagging also supports styling for right-to-left languages and other language-specific behaviors.
+
+## User preference
+
+Modern CSS includes [User Preference Media Queries](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/@media/prefers-color-scheme) that let websites adapt to a user's operating system or browser settings. Users get a more comfortable, personalized experience. Websites can respond to preferences for motion, contrast, and color schemes.
+
+{{ figure_markup(
+ image="user-preference-media-query.png",
+ caption="User preference media queries.",
+ description="A bar chart comparing the share of pages that use various user preference media features on desktop and mobile. The most widely used feature is `prefers-reduced-motion`, appearing on about half of both desktop (49.99%) and mobile (50.55%) pages. `-ms-high-contrast` and `forced-colors` also show notable usage, at around 21% and 16% on desktop and 20% and 19% on mobile, respectively. Other features, such as `prefers-color-scheme` (about 13% on both platforms) and `prefers-contrast` (around 1%), are used much less, while several legacy or experimental features appear on virtually no pages.",
+ chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQFD-7C6Jv6q1JyviDsKosRlVwaok7g7nRCQ9NGMw5MaAAohL7EcDejVwgp13Z_T2S_57Zi0YaVb7st/pubchart?oid=1063383428&format=interactive",
+ sheets_gid="1601070335",
+ sql_file="media_query_features.sql",
+ width=600,
+ height=551
+ )
+}}
+
+The most familiar queries, `prefers-reduced-motion` and `prefers-color-scheme`, remain widely supported by browsers. In 2025, adoption of these queries by websites shows little change. However, the use of `forced-colors`, which supports high-contrast modes for users with low vision, increased by 5% to 19%. Meanwhile, use of the outdated `-ms-high-contrast` media query has declined by 3% down to 20%. This reflects a gradual shift towards modern CSS standards.
+
+Continuing to incorporate these preferences advances accessibility and user satisfaction by respecting individual needs and system settings.
+
+Broader implementation of personalization through CSS media queries hasn't seen significant growth despite these incremental gains. Encouraging further adoption helps ensure websites honor users’ preferences, including reducing motion for vestibular disorder sensitivities and adapting display colors or contrast for visual comfort.
+
+## Navigation
+
+Users navigate websites in different ways. Some use a mouse to scroll. Others use a keyboard, switch control device, or screen reader to navigate through headings. An effective navigation system must work for every user, regardless of their input device.
+
+Wide-screen TVs and voice interfaces like Siri and Amazon Alexa create unique navigation challenges. Building good semantic structure into a site helps screen reader users navigate. It also helps users of many other types of technology.
+
+### Focus indication
+
+Focus indication is essential for users who rely primarily on keyboard navigation and assistive devices to move through web content. It provides a visible cue that highlights which element is currently focused, so users understand where they are on the page.
+
+Automated testing tools like Google Lighthouse can identify many basic requirements and flag obvious failures around focus indicators. But they're limited when it comes to complex interactions like keyboard traps, focus order, and whether focus moves logically to new content. Passing automated audits doesn’t guarantee a site’s keyboard accessibility or a good user experience for keyboard users.
+
+Comprehensive manual testing is irreplaceable.
+
+Tools like the open source Accessibility Insights for the Web extension leverage Deque's axe-core and offer guided manual tests. The "Tab Stops" visualization feature helps testers see the path keyboard users take and identify potential issues effectively, like missing focus styles or unexpected focus traps.
+
+Users of alternative navigation devices with limited motor abilities have unique needs related to focus visibility and sequence. Customizing assistive technology interfaces helps maximize control tailored to their abilities.
+
+Focus testing best practices include:
+
+- No focus traps where keyboard users get stuck
+- All interactive controls are keyboard focusable
+- Tab order is logical and intuitive
+- Focus is appropriately directed to new or dynamically loaded content
+
+The A11y Collective's report on understanding focus indicators offers practical insights for implementing and testing visible focus outline styles.
+
+#### Focus styles
+
+WCAG mandates that all interactive content must have a clearly visible focus indicator. This visual cue helps keyboard users identify which element is currently focused as they move through the page.
+
+Without a prominent focus indicator, keyboard users and those relying on assistive technologies can easily become lost. Robust focus styles, like a high-contrast outline, are fundamental to accessible design. Many institutions, like GOV.UK, have established standards for focus indicators to ensure consistency and clarity.
+
+Design annotations need to specify keyboard interactions, as Craig Abbott clearly laid out in the TetraLogical blog. Shortly after this post, GitHub released their accessibility Annotation Toolkit, addressing the same problem.
+
+{{ figure_markup(
+ image="pages-overriding-browser-focus-styles.png",
+ caption="Pages overriding browser focus styles.",
+ description="A bar chart comparing the share of pages that use three focus-related CSS patterns on desktop and mobile. The basic `:focus` selector is present on about 90% of both desktop and mobile pages, while removing focus outlines with `:focus { outline: 0; }` appears on roughly two-thirds of pages (67%) for both. Usage of the more accessible `:focus-visible` selector is much lower, at about one-quarter of pages (25% on desktop and 24% on mobile).",
+ chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQFD-7C6Jv6q1JyviDsKosRlVwaok7g7nRCQ9NGMw5MaAAohL7EcDejVwgp13Z_T2S_57Zi0YaVb7st/pubchart?oid=1774339890&format=interactive",
+ sheets_gid="1499298533",
+ sql_file="focus_outline_0.sql"
+ )
+}}
+
+In 2025, 67% of sites explicitly removed default focus outlines, up 14% from 2024. This concerning trend may impair accessibility if not replaced with effective styles. On the positive side, adoption of the `:focus-visible` pseudo-class has grown. This means developers are starting to create context-aware focus indicators that are visible only when necessary.
+
+#### `tabindex`
+
+The `tabindex` attribute controls an element's participation in the keyboard focus order. It lets developers include, exclude, or reorder focusable elements. Correct use supports logical navigation and accessibility, and is a WCAG requirement. Misuse, especially with positive values, can disrupt natural tab order and confuse users.
+
+{{ figure_markup(
+ image="tabindex-usage.png",
+ caption="`tabindex` usage.",
+ description="A bar chart showing the share of pages that use different `tabindex` values on desktop and mobile. Just over half of pages use `0` (52.1% on desktop and 50.1% on mobile), and a similar share use negative `tabindex` values such as `-1` (52.0% on desktop and 50.3% on mobile). In contrast, positive `tabindex` values appear on only a small minority of pages (3.7% on desktop and 3.4% on mobile).",
+ chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQFD-7C6Jv6q1JyviDsKosRlVwaok7g7nRCQ9NGMw5MaAAohL7EcDejVwgp13Z_T2S_57Zi0YaVb7st/pubchart?oid=140565248&format=interactive",
+ sheets_gid="1566430802",
+ sql_file="tabindex_usage_and_values.sql"
+ )
+}}
+
+In 2025, `tabindex` usage has increased slightly. Just over 50% of sites used it, around 3-4% higher than 2024. Positive `tabindex` use remains stable, generally low, reflecting continued awareness that positive tabindex values should be avoided.
+
+### Landmarks
+
+Landmarks structure a web page into distinct thematic regions, using native HTML elements such as ``, `