The Web Content Accessibility Guidelines (WCAG) are internationally recognized recommendations for making websites and digital content more accessible to people with disabilities. For a library web team, WCAG 2.2 provides the most current stable target: design and test content against the four principles of perceivable, operable, understandable, and robust access; prioritize Level AA; and document exceptions and remediation. This approach matters because the World Health Organization estimates that 1.3 billion people, or about 16% of the global population, experience significant disability, while WebAIM’s 2024 Million report found detectable WCAG failures on 95.9% of the one million homepages it evaluated.
Define WCAG standards as accessibility conformance
WCAG standards are testable web accessibility requirements developed by the World Wide Web Consortium’s Web Accessibility Initiative. The W3C defines WCAG as a shared international standard for making web content more accessible to people with disabilities, including people with auditory, cognitive, neurological, physical, speech, and visual disabilities.
The Entity Attribute Pairing in this topic is “WCAG standards—accessibility conformance.” Accessibility conformance describes the degree to which a website, page, application, or digital document satisfies applicable WCAG success criteria. WCAG itself is not a law; governments and institutions may incorporate it into laws, regulations, procurement rules, contracts, or internal policies. For libraries, conformance is therefore both a technical quality measure and a way to support equitable access to catalogs, databases, research guides, event registration, room reservations, and digital collections.
WCAG versions and stable implementation targets
WCAG 2.0 became a W3C Recommendation in 2008, WCAG 2.1 in 2018, and WCAG 2.2 in October 2023. WCAG 2.2 preserves the WCAG 2.1 success criteria while adding nine criteria, including requirements related to focus appearance, dragging alternatives, accessible authentication, consistent help, and minimum target size. WCAG 2.2 contains 86 success criteria across Levels A, AA, and AAA.
A library team should normally select WCAG 2.2 Level AA as its internal target unless a governing policy specifies another version. WCAG 2.2 is backward compatible with WCAG 2.1: content that conforms to WCAG 2.2 also conforms to WCAG 2.1, provided the same level is being compared. Teams should record the selected version and level in accessibility statements, project requirements, vendor contracts, and testing plans.
The four WCAG principles
WCAG organizes accessibility requirements under four principles, often abbreviated as POUR. Perceivable content can be received through more than one sensory channel; operable interfaces can be used with different input methods; understandable content and controls behave predictably; and robust content works with current and future user agents, including assistive technologies.
These principles contain 13 guidelines, which establish broad objectives, and success criteria, which provide testable requirements. Techniques and failures published by the W3C offer implementation guidance, but techniques are informative rather than a complete checklist. A library team should test the outcome required by each success criterion instead of assuming that a particular code pattern automatically proves compliance.
Measure WCAG standards through conformance levels
WCAG conformance levels are graded A, AA, and AAA. Level A addresses the most basic barriers, Level AA addresses a broader and generally practical set of accessibility requirements, and Level AAA represents the highest level of conformance. The W3C does not recommend requiring AAA conformance for an entire website because some AAA criteria cannot reasonably be applied to all types of content or organizations.
Level A as a minimum accessibility baseline
Level A criteria address barriers that can prevent people from accessing or using content at all. Examples include providing text alternatives for meaningful images, ensuring that information is not conveyed by color alone, supplying captions for prerecorded audio in synchronized media, and making keyboard operation possible.
For a library, Level A failures may make a catalog search result incomprehensible to a screen-reader user, prevent keyboard-only navigation through a form, or hide the purpose of an icon from someone with low vision. Automated testing can identify some missing alternative text or keyboard-focus problems, but staff must also perform manual checks because automation cannot reliably judge whether an alternative text description is meaningful.
Level AA as the practical library target
Level AA adds requirements that address common and significant barriers. Examples include minimum color contrast, meaningful focus visibility, responsive reflow, consistent navigation, error identification, accessible labels, captions for live audio, and content that remains usable when text is enlarged.
Level AA is a common procurement and regulatory benchmark because it balances broad user benefit with practical implementation. The U.S. Department of Justice’s 2024 rule for state and local government web content and mobile applications references WCAG 2.1 Level AA, while the European Accessibility Act began applying to many covered products and services in June 2025. These developments do not make every library subject to the same legal obligations, but they demonstrate why accessibility requirements should be addressed during procurement rather than after launch.
Level AAA as a targeted enhancement
Level AAA criteria can be valuable for particular audiences, services, or collections even when an entire site is not pursuing AAA. A library might voluntarily use enhanced sign-language interpretation, extended audio description, simpler language, or more demanding contrast and readability practices for children’s resources, health information, emergency notices, or specialized learning materials.
The appropriate goal is not to label a site “AAA” without satisfying every applicable AAA criterion. Instead, teams should identify high-impact improvements, explain their scope, and validate them with users who have relevant disabilities.
Apply WCAG standards to library content and services
WCAG applies to more than the library’s homepage. The scope should include the discovery layer, catalog interface, databases, institutional repository, digital exhibits, event calendars, online forms, downloadable documents, embedded media, authentication flows, chat services, and third-party platforms purchased by the library.
Perceivable content: alternatives, structure, and presentation
Perceivable content gives users equivalent ways to receive information. Library teams should provide meaningful alternative text for informative images, empty alternative text for decorative images, captions and transcripts for audiovisual material, descriptive headings, labeled form fields, and sufficient contrast. A scanned historical document may require optical character recognition and a human review, because a visually accurate image alone may not be searchable or usable with a screen reader.
Responsive design is also part of perception and use. Under WCAG 2.2, content should generally reflow without loss of information or functionality at narrow viewport widths and high zoom levels. Teams should test databases and embedded services on mobile screens rather than assuming that a responsive library template makes every vendor interface accessible.
Operable interfaces: keyboard, focus, timing, and navigation
Operable interfaces support keyboard users, people who use switch devices or voice control, and people who need additional time. Every interactive function should have a visible and logical focus order, focus should not be hidden behind sticky headers or dialogs, and users should be able to dismiss or recover from interruptions. Menus, carousels, modal windows, filters, and date pickers deserve specific keyboard testing because these components frequently fail despite appearing functional with a mouse.
WCAG 2.2 also adds requirements concerning dragging alternatives, focus appearance, and minimum target size. A library’s room-reservation calendar, for example, should not require dragging to select a time and should provide a keyboard-accessible alternative with sufficiently large controls.
Understandable content: language, consistency, and error recovery
Understandable content uses clear language, predictable navigation, consistent labels, and helpful instructions. Forms for library cards, interlibrary loans, study-room bookings, and program registration should identify errors in text, associate errors with the relevant fields, preserve entered information when possible, and explain how to correct the problem.
Plain language improves accessibility for people with cognitive and learning disabilities and benefits many other users. A library should explain technical terms such as “proxy authentication,” “persistent link,” or “metadata” when those terms are necessary, rather than treating specialist vocabulary as self-explanatory.
Robust content: semantic code and assistive technology compatibility
Robust content uses valid, semantic structures that browsers and assistive technologies can interpret consistently. Correct heading hierarchy, native HTML controls, programmatically associated labels, descriptive page titles, and appropriate status messages are usually more reliable than custom widgets built from generic containers.
The Accessible Rich Internet Applications specification can supplement native HTML when a complex widget requires additional semantics, but ARIA cannot repair every interaction problem. The practical validation question is whether users can identify, operate, and understand the interface with the assistive technologies they use.
Validate WCAG standards with layered testing
No single audit method can prove accessibility. WebAIM’s 2024 Million report illustrates the scale of the challenge: 95.9% of tested homepages had detectable WCAG failures, with an average of 56.8 errors per page. Automated tools are valuable for finding repeated issues, but they do not determine whether image descriptions are accurate, whether headings make sense, or whether a complex workflow is usable.
Automated, manual, and assistive technology review
A mature library testing program combines automated scans, keyboard-only review, visual inspection at high zoom, color and contrast checks, code inspection, and testing with screen readers such as NVDA, VoiceOver, or JAWS. Teams should test representative templates and workflows, including search, login, payment or donation, registration, document download, media playback, and error recovery.
User testing with people who have disabilities is especially important. It reveals barriers that a standards audit may miss and helps the library prioritize issues according to actual impact. Testing participants should be compensated, accessibility requirements should be identified in advance, and user feedback should not be treated as a substitute for conformance testing or as a burden placed on individual patrons.
Governance, procurement, and continuous improvement
Accessibility should be assigned to owners across content, design, development, procurement, communications, and public services. Each issue should have a severity, affected users, responsible owner, target date, status, and verification method. The team should also maintain an accessibility statement that provides a contact method and explains known limitations without shifting responsibility to patrons.
Vendor contracts should require an applicable WCAG version and level, an accessibility conformance report such as a completed VPAT or equivalent, accessible support and documentation, remediation timelines, and the right to test updates. A vendor’s statement of conformance is evidence to review, not a replacement for testing the actual library configuration.
A useful visual for the web team is a quarterly accessibility dashboard showing open findings by WCAG principle, severity, content type, and vendor. A second chart can compare automated error counts with manually verified barriers, making clear that a declining scan total does not necessarily mean that real-world usability has improved.
Conclusion: make WCAG standards part of library service quality
WCAG standards define accessibility conformance through principles, guidelines, success criteria, techniques, and three conformance levels. For most library web teams, WCAG 2.2 Level AA is a strong current target, supported by semantic HTML, accessible content practices, inclusive procurement, layered testing, and ongoing remediation. Level A barriers should be addressed urgently, Level AA should guide normal service delivery, and selected Level AAA practices can improve high-impact resources.
The broader implication is that accessibility is not merely a compliance exercise or a final quality-control step. It is a core library service commitment that affects discovery, learning, civic participation, privacy, and equal access to information. The next practical step is to inventory every public-facing digital service, choose a documented WCAG target, test the highest-value user journeys with disabled users, and publish a prioritized remediation plan.
Sources: World Wide Web Consortium, Web Content Accessibility Guidelines (WCAG) 2.2, https://www.w3.org/TR/WCAG22/; World Wide Web Consortium, Web Content Accessibility Guidelines (WCAG) 2.1, https://www.w3.org/TR/WCAG21/; World Health Organization, Disability and Health, https://www.who.int/news-room/fact-sheets/detail/disability-and-health; WebAIM, The WebAIM Million: The 2024 Report, https://webaim.org/projects/million/2024/; U.S. Department of Justice, Nondiscrimination on the Basis of Disability in State and Local Government Services, https://www.ada.gov/resources/2024-03-08-web-rule/; European Commission, European Accessibility Act, https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/union-of-equality/european-accessibility-act_en.