Special Episode: Chapter 3 - Real. Relevant. Required.

This episode is a reading of Chapter 3 from Real. Relevant. Required.: A Practitioner's Guide to ADA Title II Digital Accessibility for State and Local Government by Becky Rehorn. The rule requires WCAG 2.1 Level AA. But what does that actually look like when you are sitting in front of a document, a website, or a public comment portal? Chapter 3 walks through the four principles that organize the standard (Perceivable, Operable, Understandable, and Robust), explains what the 50 testable success criteria at Levels A and AA require in plain language, and connects each principle to the specific content types that transportation agencies and AEC firms produce every day. This is not a technical manual. It is a practitioner's translation of what the standard means for the work you are already doing. For the next several weeks, Access Brief is sharing chapters from the book, available now on Amazon.

Access Brief is produced by Accessible Organizations Group LLC.

Transcript

Copy Transcript Copied

SPEAKER_00 0:00

You are listening to the Access Brief Podcast Edition of the Book Real Relevant Required. My name is Becky Rehorn. We are continuing Part one Real. In chapter one, we looked at how we got here. In chapter two, we opened and discussed the rule itself, what it requires, and who it covers. Chapter three is where we get to the standard the rule points to WCAG two point one level double A. WCAG gets cited constantly in compliance conversations, but very few of the people responsible for implementing it have ever read it. That's not a criticism. The full specification runs more than a hundred pages, and it was written for people building web technology from the ground up, not for someone updating a web page or laying out a public document. This chapter is the translation. We'll cover what WCAG is and what it is not, how the four principles work in practice, and where automated testing ends and human judgment begins. Chapter three WCAG two point one level double A in practice. The web content accessibility guidelines are widely cited in public sector compliance conversations, but rarely read in full by the practitioners responsible for implementing them. The full two point one specification, as published by the World Wide Web Consortium, spans more than a hundred pages of technical prose. The authors were careful, rigorous, and aware that the standard had to work across a vast range of content types, technologies, and user needs. They were not in general writing for the people who create public facing content using tools like Word, InDesign, or a content management system CMS. The specification treats its readers as implementers building accessibility into web technology from the ground up, not as practitioners working within tools someone else has already built. This chapter is the translation. It covers what WCAG is, how it is organized, what each of the four principles means in practice, and where the boundary sits between what automated testing can catch and what it cannot. Appendix A provides a complete reference to every level A and level AA success criterion in plain language, grouped by principle, designed as a working checklist you can return to after finishing the book. What WCAG is and what it is not WCAG is a technical standard, not a law. It was published by the World Wide Web Consortium, an international standards body, as a recommendation for how to make web content accessible to people with disabilities. Governments around the world, including the United States under the April 2024 final rule, the European Union, the United Kingdom, and Canada, have adopted WCAG by reference as the legal standard the agencies they govern must meet. But WCAG itself is a consensus technical document, not a regulation. The distinction matters in two practical ways. First, WCAG is updated on its own timeline, not the government's. The standard has gone through three major versions since 2008, each building on the last. The april twenty twenty four final rule specifies WCAG two point one as the binding version. A newer version, WCAG two point two, was published in 2023 and is permitted under the equivalent facilitation provision discussed in chapter two, but it is not required. Agencies that choose to adopt 2.2 are meeting and exceeding the rule standard. Second, WCAG is designed to be testable. Each success criterion is written to be evaluated as pass or fail against a specific piece of content. That testability is what makes WCAG useful as a legal standard. And it is also what makes WCAG surprisingly manageable once a practitioner understands the structure. The POR framework. WCAG organizes every requirement under four principles known by the acronym POR, perceivable, operable, understandable, robust. The W3C specification defines these formally, the working questions we discuss next, translate each one into plain language. Perceivable. Can the user sense the content? Can they see it, hear it, or have it read aloud by assistive technology? Operable. Can the user interact with the content? Can they navigate it, activate its controls, and move through it at their own pace? Understandable. Can the user comprehend the content? Is the language clear? Are the controls predictable? Do error messages help rather than confuse? Robust. Will the content work reliably across different browsers, devices, and assistive technologies now and as those technologies evolve? Under each principle sits a set of guidelines. Under each guideline sits a set of testable success criteria, each tagged as level A, AA, or AAA. The april twenty twenty four final rule requires conformance to all level A and level AA criteria in WCAG two point one fifty criteria in total. Perceivable in practice The perceivable principle is about whether the user can actually get to the content, whether they can see it, hear it, or have it read to them by assistive technology. In my daily work, perceivable is the principle that determines whether a document works with my assistive technology or against it. A PDF with a logical heading structure, a reading order that matches the visual layout, an alt text on every meaningful image lets me listen through it at a pace that keeps my attention engaged. A PDF that was exported from a design program without any of that structure forces me to fight the tool rather than use it, spending significantly more time and cognitive energy to get the same information. The following examples show what perceivable looks like when it is done well. A project website image, a rendering of a proposed intersection, for example, carries alt text that describes what the rendering shows. A screen reader user hears Proposed Intersection of Main Street and Fifth Avenue showing a raised median, two crosswalks, and a pedestrian refuge island instead of image three dot JPG. An annual budget document posted as a PDF includes tagged headings, revenue, expenditures, debt service, capital projects, so a screen reader user can move through the document by section the way a cited reader skims a table of contents. A city council meeting live stream includes accurate captions either live or added within a short and documented window after the event. A zoning map page's text meets the minimum contrast ratio 4.5 to 1 for regular text, 3 to 1 for large text against its background, so low vision users can read it without assistive magnification. Operable in practice. The operable principle asks whether the user can interact with the content once they perceive it. It is the principle most directly concerned with users who navigate by keyboard rather than mouse, users with limited dexterity or fine motor control, and users who need extra time to complete tasks. Keyboard navigation is the test most practitioners underestimate. A permit application portal that can be filled out by a keyboard user who tabs through fields in a logical order, sees a clear focus indicator on each field, and can submit without reaching for a mouse is operable. A portal that can only be completed by dragging items or clicking specific screen regions is not. A few examples illustrate the point. An open data portals navigation menu can be opened and used entirely with keyboard keys. A user can press tab to move through menu items, enter to activate a link, and escape to close a submenu. A utility bill payment form allows enough time for a user to read, respond, and submit without being kicked out by an invisible session timer. A public records request video tutorial embedded on an agency page does not autoplay with flashing content, and any animation can be paused. A community survey clearly labels each required field and tells the user which fields have errors without relying solely on color. For example, a red outline and a text message. Understandable in practice. The understandable principle asks whether the user can make sense of the content and the interface. It is the principle most directly concerned with users who have cognitive disabilities, learning disabilities, limited literacy, or who are reading in a language other than their first. Understandable is often the principle that benefits users well beyond those with diagnosed disabilities. Plain language, predictable navigation, and clear error messages make content easier for everyone, including the stressed commuter trying to comment on a corridor study during a lunch break. Consider these examples. A public notice of a public participation meeting is written in plain language at an appropriate reading level with abbreviations defined on first use. The navigation menu on a county transit agency's website appears in the same place with the same items on every page. A user who learned how to find the route schedule on page one does not have to relearn it on page five. When a user submits a building permit application with a missing required field, the error message points to the specific field, for example, contractor license number is required, rather than a generic submission fail that forces the user to guess. The page declares its primary language so a screen reader pronounces the content correctly, and any passages in another language, a Spanish language summary, for example, are marked so the screen reader shifts pronunciation accordingly. Robust in practice. The robust principle asks whether the content will work reliably across the full range of browsers, devices, and assistive technologies a user might bring to it. It is the principle most directly concerned with the technical foundation of the content, and it is where most of the work is usually done by developers rather than content authors. Robust is the smallest of the four principles in terms of success criteria, but it is not the least important. A site that fails on robust will fail inconsistently, working for some users and not others in ways that are hard to diagnose. Examples of what Robust looks like in practice follow. The site's code identifies each interactive element button link form field with a proper name and role, so a screen reader announces submit button rather than clickable element. Status messages, a confirmation that a public records request was submitted, for example, or an alert that a search of a municipal open data portal returned no results, are coded in a way that assistive technology announces them without requiring the user to navigate back to find them. The code conforms to the technical specifications of the languages used HDML, CSS, JavaScript, so that different browsers and screen readers interpret it consistently. Level double A versus level triple A WCAG's three conformance levels are not a menu of stringency, they are a structured progression and each higher level incorporates everything below it. Level A is a starting point. A site that fails level A criteria has fundamental accessibility barriers that prevent some users from accessing the content at all. Level AA adds requirements that address the most common and practically significant accessibility issues. It is the level most often adopted by governments, major private sector organizations, and international standards. It is the level the April 2024 final rule requires. Level triple A adds requirements that are either more stringent versions of AA criteria, higher contrast ratios, for example, or that address specific use cases, sign language interpretation of prerecorded audio, for example. WCAG itself advises that level triple A is not appropriate as a blanket requirement for all content because some criteria cannot be satisfied for some types of content. This book focuses on level AA, the standard the rule requires. The limits of automated testing Automated Accessibility Testing does not catch everything. The Web AIM Million Report, an annual evaluation of the top one million websites now in its eighth year, found in twenty twenty six that ninety five point nine percent of home pages contained at least one detectable WCAG failure, with an average of fifty six point one errors per page. Those numbers actually worsened from the prior year, reversing a trend of small improvements. That is a reminder that the problem is not solving itself. And those are only the errors an automated scanner can detect. Automated tools check for the presence or absence of code features, whether an image has alt text, whether a form field has a label, whether a color combination meets a contrast ratio. They cannot evaluate whether the alt text is meaningful, whether the reading order makes sense, or whether a screen reader user can actually complete a form. Those are subjective questions only a human can answer. This matters because a clean automated scan is not evidence of compliance. It is evidence that the scan's questions have been answered. The remaining failures, which only manual review will reveal, are still present and still create enforcement exposure. Automated testing belongs in every compliance program as a fast, scalable first step, but it is the first step, not the last. Chapter seven addresses how to combine automated and manual testing in practice. Appendix A at the end of this book provides a complete reference to all 50 level A and AA success criteria in WCAG 2.1, translated into plain practitioner facing language and grouped by principle and guideline. It is designed to be consulted rather than read straight through, a working reference readers can return to when evaluating a specific piece of content against the standard. With chapters one through three in hand, a practitioner has the foundation. Part two turns to the question that determines how the standard applies to specific public sector work, who has covered what counts as content in scope, and why the accommodation on request model that has served as the default for a generation is no longer enough. Chapter three has five key takeaways. Number one, WCAG is organized around four principles perceivable, operable, understandable, robust, poor. The april twenty twenty four final rule requires conformance to all fifty level A and AA criteria. Number two, automated testing catches a fraction of accessibility failures. A clean scan is not evidence of compliance, it is evidence that the scan's questions have been answered. Number three, manual review is required for the issues automated tools cannot evaluate, meaningful alt text, logical reading order, keyboard usability, inform completion. four, WCAG two point one is the required standard. WCAG two point two is permitted but not required. Build for two point one and monitor two point two. Number five, Appendix A provides all fifty criteria in plain language as a working reference. That's it for chapter three, and with it the end of part one. Real. Thank you for listening. In the next episode we begin part two, relevant, with chapter four, who is covered, and the myth of we're too small. If you have ever heard someone say the rule only applies to big cities and big agencies, this chapter is for them. As always, and until next time, keep moving forward.