Tài nguyên về khả năng tiếp cận

A short history of web accessibility

Long before there was a web, US federal law had begun building the legal scaffolding accessibility would later hook into. Section 504 of the Rehabilitation Act of 1973 prohibited discrimination on the basis of disability by any program receiving federal financial assistance, with the implementing regulations only signed on 28 April 1977 — and only after the famous 504 sit-in, in which disability-rights activists occupied a federal building in San Francisco for 25 days, the longest nonviolent occupation of a federal building in US history. Section 508 of the same act was added by amendment in 1986 but had no enforcement teeth; the substantially revised version practitioners refer to today was enacted in 1998 as part of the Workforce Investment Act, requiring US federal agencies to make their electronic and information technology accessible. The Americans with Disabilities Act of 1990 is the broader civil-rights statute prohibiting disability discrimination, and it's the ADA — not Section 508 — that's invoked in private-sector website lawsuits.

The W3C launched the Web Accessibility Initiative (WAI) in 1997 to coordinate web accessibility work across the standards-setting community. Tim Berners-Lee's framing — that the web's value rests on universality, and access by everyone regardless of disability is essential — became the WAI's founding premise.

The WCAG version timeline

• WCAG 1.0 — W3C Recommendation, 5 May 1999. Organised accessibility advice around 14 guidelines with checkpoints rated Priority 1, 2, or 3 (the conformance levels A, AA and AAA inherit from this scheme). Firmly oriented around HTML and the early-web stack of the late 1990s.
• WCAG 2.0 — W3C Recommendation, 11 December 2008. Reorganised the entire framework around the four POUR principles. Introduced the still-current three-tier conformance model (A / AA / AAA). Adopted as ISO/IEC 40500:2012 in October 2012.
• WCAG 2.1 — W3C Recommendation, 5 June 2018. Added 17 new success criteria addressing mobile users (screen orientation, pointer gestures, motion actuation), low-vision users (320 CSS-pixel reflow, 3:1 non-text contrast for UI components, text-spacing tolerance), and people with cognitive and learning disabilities (autofill input-purpose, timeout help). "WCAG 2.1 AA" remains the most-cited standard in accessibility law worldwide.
• WCAG 2.2 — W3C Recommendation, 5 October 2023, with editorial maintenance updates published December 2024. Added nine new success criteria including Focus Not Obscured (2.4.11/2.4.12), Dragging Movements (2.5.7), Target Size Minimum (2.5.8 — at least 24×24 CSS pixels), Consistent Help (3.2.6), Redundant Entry (3.3.7), and Accessible Authentication (3.3.8/3.3.9 — login flows can't require puzzle CAPTCHAs without an accessible alternative). Removed the obsolete 4.1.1 Parsing criterion. This is the current published version.
• WCAG 3.0 — still a Working Draft. Designed with a more flexible scoring model and broader scope (apps, authoring tools, publishing platforms, emerging tech). The W3C is clear that WCAG 3 will not supersede WCAG 2 immediately — WCAG 2 will continue to be maintained for several years after 3 is finalised. Practitioners writing accessibility statements in 2026 should still reference WCAG 2.2 (or 2.1) as the operative standard.

The four POUR principles in plain English

Perceivable asks: can the user actually take in what's on the screen? A photograph with no alt text is not perceivable to someone using a screen reader. A video with no captions is not perceivable to someone who is deaf. Text in 9-point dark grey on slightly less dark grey is not perceivable to many people with low vision. "Perceivable" doesn't mean "looks pretty" — it means "is the information present in a form this user's senses and tools can pick up?"

Operable asks: can the user actually use the interface? A site that requires hovering with a mouse is not operable for keyboard or touch users. A 60-second timeout is not operable for someone who needs longer to read. A modal that traps keyboard focus with no escape is not operable.

Understandable asks: can the user make sense of what's happening? A form that says "Error 47" and nothing else is not understandable. A page where the navigation rearranges itself differently every visit is not understandable.

Robust asks: will the content still work as user agents and assistive technologies evolve? Custom components that don't expose proper roles, names, and states to the accessibility tree fail this principle. The most common practical advice: prefer standard HTML elements over custom JavaScript widgets where possible; when you do build custom widgets, follow the ARIA patterns documented by the W3C.

WAI-ARIA, the rich-application companion

WAI-ARIA is a separate W3C specification that defines roles, states and properties HTML can carry to communicate the purpose and current state of dynamic interface components to assistive technologies. ARIA is needed because HTML alone can't describe modern patterns like tabs, dialogs, autocomplete combo-boxes, tree views, and live regions that update without a page reload. Version timeline: WAI-ARIA 1.0 Recommendation 20 March 2014; 1.1 on 14 December 2017; 1.2 on 6 June 2023 — the current version. The five "rules of ARIA use" boil down to: prefer native HTML; don't change the semantics of existing elements; ensure keyboard operability; never hide focusable elements from assistive tech; and always give every interactive element an accessible name.

The legal landscape, jurisdiction by jurisdiction

In the United States, web accessibility lawsuits are filed almost entirely under ADA Title III. Two cases set the modern landscape. National Federation of the Blind v. Target Corp. (filed 7 February 2006, settled August 2008 for $6 million plus $3.7 million attorney's fees) was the first major US web-accessibility class action. Robles v. Domino's Pizza — Ninth Circuit ruling on 15 January 2019; Supreme Court declined to hear the appeal on 7 October 2019 — confirmed the ADA reaches any online platform of a US business with physical locations. The result has been a sustained boom in filings: 4,187 federal digital-accessibility lawsuits in 2024, with more than 4,000 each year since 2021. About a quarter of 2024 cases involved companies that had already been sued before. Notably, more than 1,000 of the 2024 defendants had already installed an "accessibility widget" — the overlay-style scripts heavily marketed to small businesses — which did not prevent the suit.

In April 2024 the US Department of Justice finalised a long-awaited rule applying ADA Title II to state and local government web content and mobile apps. The rule was published in the Federal Register on 24 April 2024 and adopted WCAG 2.1 Level AA as the technical standard. In April 2026 the DOJ extended the original deadlines by one year via Interim Final Rule: large public entities now have until 26 April 2027, small entities until 26 April 2028.

The European Accessibility Act is Directive (EU) 2019/882, adopted in April 2019. Member states had to transpose it into national law by 28 June 2022, and the substantive accessibility requirements began applying on 28 June 2025. The EAA covers a wide range of consumer products and services placed on the EU market: computers and operating systems, smartphones and tablets, e-readers, ATMs and ticketing/check-in machines, e-commerce websites, banking services, e-books, audiovisual media services, and passenger-transport information. Microenterprises (fewer than 10 employees, turnover under €2 million) providing services are exempt. The harmonised technical standard is EN 301 549, jointly published by CEN, CENELEC and ETSI; current version 3.2.1 (March 2021) incorporates the full text of WCAG 2.1.

Other significant national frameworks: Ontario's AODA (Accessibility for Ontarians with Disabilities Act), enacted in 2005 with a stated goal of full accessibility by 2025; France's RGAA (Référentiel Général d'Amélioration de l'Accessibilité) v4.1.2 (2022) — a set of 106 technical criteria mapped to WCAG 2.1 AA, with substantial fines for non-compliance by public-sector and large private companies (annual turnover €250 million or more).

Who's actually using your site — the assistive-tech landscape

The most reliable data on screen reader and browser combinations comes from the WebAIM Screen Reader User Survey. The most recent edition, Survey #10, was conducted December 2023 – January 2024 and drew 1,539 valid responses. Headline numbers: as primary screen reader, JAWS 40.5%, NVDA 37.7%, VoiceOver 9.7%. As "most commonly used at all" (multiple choice), NVDA 65.6%, JAWS 60.5%, VoiceOver 43.9% — about 71.6% of respondents use more than one screen reader. The most common combinations are JAWS + Chrome (24.7%), NVDA + Chrome (21.3%), JAWS + Edge (11.4%), NVDA + Firefox (10.0%), and VoiceOver + Safari (7.0%).

• JAWS (Job Access With Speech) — commercial Windows screen reader, originally released in 1989 by Ted Henter through Henter-Joyce, now part of Vispero. Dominant in US enterprise and government.
• NVDA (NonVisual Desktop Access) — leading free open-source Windows screen reader, first released April 2006 by Michael Curran and James Teh (both blind themselves). The non-profit NV Access was established in early 2007. NVDA's growth has been the most striking trend in the screen-reader market over the past decade.
• VoiceOver — built into Apple's operating systems. Debuted in Mac OS X 10.4 Tiger (2005); added to iOS with the iPhone 3GS (2009). Now ships on macOS, iOS, iPadOS, tvOS and watchOS.
• TalkBack — the equivalent built-in screen reader on Android, maintained by Google.

Other assistive technologies in the broader ecosystem: screen magnifiers (ZoomText for Windows, the built-in macOS magnifier), speech-recognition software (Dragon NaturallySpeaking), switch-access devices for users with limited motor control, alternative keyboards and head-pointers, eye-tracking systems, and refreshable braille displays. WCAG criteria address all of these even when the page only thinks about screen readers.

Colour contrast — the WCAG 2 model and the APCA candidate

WCAG 2.x measures contrast as a luminance ratio between two colours — a number from 1:1 (no contrast) to 21:1 (pure white on pure black). The thresholds: Level AA, normal text 4.5:1; large text (18 pt or 14 pt bold) 3:1; Level AAA, normal text 7:1; large text 4.5:1. WCAG 2.1's §1.4.11 Non-Text Contrast added a 3:1 requirement at AA for UI components and graphical objects that convey information.

The luminance-ratio model has known weaknesses, particularly that it overstates the perceived contrast of dark colours — a 4.5:1 pair of two dark colours can be functionally unreadable even though it technically passes. APCA (Accessible Perceptual Contrast Algorithm), developed by Andrew Somers, is a perception-based replacement designed for self-illuminated displays. It's the candidate contrast method for WCAG 3.0, not currently part of any published WCAG version. APCA produces a signed number on roughly a -108 to +108 scale (negative when light text sits on a dark background). Practitioners shipping in 2026 should still test against WCAG 2.x ratios as the legal requirement, treating APCA scores as supplementary perceptual sanity checks.

The state of the field, in numbers

The most cited annual snapshot is WebAIM's Million report, which since 2019 has run automated accessibility checks against the home pages of the top one million websites worldwide. The WebAIM Million 2026 edition, published March 2026, is the most recent at the time of writing. 95.9% of home pages had detected WCAG 2 failures (up from 94.8% in 2025 — the first reversal of a six-year improving trend). The average page had 56.1 detected accessibility errors, a 10.1% year-on-year increase. The six most common error types account for about 96% of all detected issues:

1. Low-contrast text — 83.9% of pages, average ~34 instances per page
2. Missing alt text on images — 53.1%
3. Missing form labels — 51.0%
4. Empty links — 46.3%
5. Empty buttons — 30.6%
6. Missing document language declaration — 13.5%

For background: 1.3 billion people worldwide — about 16% of the global population, or roughly 1 in 6 — experience significant disability, per the World Health Organization fact sheet last updated 7 March 2023.

Where the resources in this directory come from

The directory above pulls from the small number of organisations and projects that effectively define the field:

• W3C Web Accessibility Initiative (WAI). The standards body itself. The two most active working groups for site teams are the Accessibility Guidelines Working Group (which maintains WCAG) and the ARIA Working Group (which maintains WAI-ARIA). The WAI publishes overview pages, deep-dive technical specs, the Quick Reference, and free educational courses on edX.
• WebAIM (Web Accessibility In Mind). Founded in 1999 at Utah State University's Center for Persons with Disabilities. Operates the WAVE evaluation tool, runs the Screen Reader User Survey and the WebAIM Million, and publishes one of the most consulted libraries of practical accessibility articles on the web.
• Deque Systems. Founded in 1999, headquartered in Herndon, Virginia. Publisher of the axe-core rules engine, which it open-sourced in June 2015. Deque also runs Deque University and produces the axe DevTools browser extension that's now the industry-default automated tester.
• A11Y Project. A community-driven, open-source resource and pattern library founded in 2013. Best known for its widely shared accessibility checklist; the entire site is on GitHub for community contribution.
• International Association of Accessibility Professionals (IAAP). Professional body founded 19 March 2014, became a division of G3ict in July 2016. Administers the recognised industry certifications (CPACC, WAS, CPWA, ADS).
• MDN Web Docs. Mozilla's developer reference, including the maintained accessibility section that documents ARIA, semantics and accessibility patterns from a developer-implementation angle.

Putting all of this together: the practical answer to "which standard should I comply with" in 2026 is WCAG 2.1 AA as a floor (because most laws still cite it) and WCAG 2.2 AA as the forward-looking target. The practical testing-tool answer is axe DevTools for automation plus a real screen reader (NVDA + Chrome on Windows, VoiceOver + Safari on macOS) for the parts no automated tool can catch — Deque itself frames axe as catching "up to 80% of issues," and most independent estimates put automated detection at 30–50% of total WCAG conformance. Manual testing with a real screen reader is still required.