Modern Accessibility

Stefik

Laws and Rules Around Disabilities are Changing

Most Accessibility Standards require an Understanding of WCAG

• The Web Content Accessibility Guidelines (I pronounce it WiCkAG) provide a set of guidelines about how to make content accessible to people with disabilities on the web
• The latest version is 2.2, but government regulations typically put it at 2.1
• There are many rules about how to make content accessible, each with numerical labels
• You document whether your content is accessible with a Voluntary Product Accessibility Template (VPAT)

​

Accessibility Rules Vary and are Changing

• Think about it like “code” for an electrical system. It is a minimum bar of what not to do
• States can adopt their own rules and many do
• Across the U.S. most public entities are required to follow Department of Justice Rules:
• Applies if you work for any public entity
• Applies if you contract for any public entity
• Rules were put in in 2024 and compliance starts in either 2026 or 2027

You can Learn WCAG by Writing a VPAT

• Download the VPAT template
• You want the one with WCAG in the title
• In this context, focus especially on the tables at the end of the document
• Notice there are typically three levels:
• A: Basic accessibility
• AA: The typical standard used in regulations
• AAA: Typically not used, but provides interesting ideas
• All else being equal, focus on A and AA
• Once filled out, you have created an Accessibility Conformance Report (ACR)

​

VPAT’s Describe how they should be marked (Copied from the template)

• Supports: The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
• Partially Supports: Some functionality of the product does not meet the criterion.
• Does Not Support: The majority of product functionality does not meet the criterion.
• Not Applicable: The criterion is not relevant to the product.

WCAG Requirements

• The rest of these slides break down the requirements into my own words
• Reading the real regulations can be helpful
• Keep in mind WCAG is partially subjective and not always clear
• Reasonable people may disagree on the meaning or my interpretation of it
• Even the Department of Justice documentation strongly implies that some things are more important than others

WCAG 2. 1 Success Criteria A

Section 1 A

• 1.1.1 Non-text content: If you have items like images, they need a text label (e.g., alternative description)
• 1.2.1 Audio-only and Video-only (Prerecorded): If the content is audio or video only, there is an alternative
• 1.2.2 Captions (Prerecorded): Include captions in time based media
• 1.2.3 Audio Description or Media Alternative (Prerecorded): Audio description is essentially an overlay. Many streaming platforms support it and an easy way to get started is to turn it on

Section 1 A continued

• 1.3.2 Info and Relationships: The structure of a webpage is extremely important. For example, you want to carefully control “headers” because tools like screen readers use them for navigation
• 1.3.2 Meaningful Sequence: Sometimes if you are reading something (e.g., paragraphs in a text) the reading sequence matters. You want to make sure this is correct in the webpage as you navigate around
• 1.3.3 Sensory Characteristics: The instructions in content should not only rely on shape, size, visual location, sound, etc

​

Section 1 A continued

• 1.4.1 Use of Color: Color should not be the only mechanism by which information is provided
• 1.4.2 Audio Control: If the audio lasts more than 3 seconds, you should be able to pause it.

Section 2 A

• 2.1.1 Keyboard: You need to be able to get to all of the content with the keyboard, not just the mouse
• 2.1.2 No Keyboard Trap: Basically, if you write something that steals the keyboard, you need to be able to get out with the keyboard. For example, maybe the escape key lets you jump away
• 2.1.4 Character Key Shortcuts: Keyboard shortcuts with only one letter need to be remappable and have special rules
• 2.2.1 Timing Adjustable: If content is timed and less than 20 hours long, it needs to be able to be turned off or adjustable

​

Section 2A continued

• 2.2.2 Pause, Stop, Hide: Moving, blinking, scrolling and auto-updating content needs to be able to adjust it
• 2.3.1 Three Flashes or Below Threshold: Avoid flashing content that does so more than 3 times per second, with some exceptions
• 2.4.1 Bypass Blocks: You can skip content that repeats itself
• 2.4.2 Page Titled: The web page has a title
• 2.4.3 Focus Order: The order of focus on a web page can matter and should preserve meaning.

Section 2A continued

• 2.4.4 Link Purpose (In Context): When writing a link, the purpose of the link should be clear from the link itself. Don’t put stuff like “Go to here” in the link (within reason)
• 2.5.1 Pointer Gestures: Unless it is essential, avoid path based gestures for pointers
• 2.5.2 Pointer Cancellation: Use the up event, not the down event, to complete the pointer and make sure it is cancellable
• 2.5.3 Label in Name: If instead of using text and styling it, you take a picture of the text, make sure the text is in the name
• 2.5.4 Motion Actuation: Unless essential, there should be an alternative to motion for actuation (e.g., use a button as an alternative)

Section 3A

• 3.1.1 Language of Page: A webpage should declare what human language it is in
• 3.2.1 On Focus: This is one is tricky to understand, but the basic idea is that focus changes don’t radically change what the page is about, the view, or other confusing things. I suspect reasonable people disagree on when it does or does not apply
• 3.2.2 On Input: Similar to 3.2.1, if you change something in the user interface, it does not change the context without a warning.

Section 3A continued

• 3.2.6 Consistent Help: Note: This is only in 2.2. Basically, if you have help content across pages, it should be in the same order everywhere
• 3.3.1 Error Identification: Imagine a user is typing and an error automatically appears telling them something is wrong. The idea is the system should tell them what it is. This rules makes sense, but keep in mind it can be hard to actualize, depending on the context of the system. For example, a system might detect there is an error, but not know what the problem is exactly

Section 3A continued

• 3.3.2 Labels or Instructions: If you have a way to input text on the screen, there should be a label or instructions for what to enter. This requirement is definitely “within reason.” There are many examples of how this could be hard or impossible to achieve (e.g., programming languages), but others where it is easy (e.g., type your name here)
• 3.3.7 Redundant Entry: Note: This is only in 2.2. If information is presented to the user, don’t make them re-type it

Section 4A

• 4.1.1 Parsing: This is in reference to having mismatched tags. It makes sense to check it, but the rule was removed in WCAG 2.2, so the recommendation in 2.1 VPATs is to just mark it as supports.
• 4.1.2 Name, Role, Value: In theory this one makes sense in that you should be able to determine the role from a user interface component. In practice, however, browsers are infuriatingly inconsistent in how they manage these roles, which can lead to problems for the user experience. Point being, this one makes sense but requires some human judgment

WCAG 2. 1 Success Criteria AA

Section 1 AA

• 1.2.4 Captions (Live): If the content is live, meaning not pre-recorded, captions are created in real-time. Note that while not perfect, automated systems have come a long way in creating high-quality real-time captions, which have pros and cons compared to humans doing it (e.g., humans are slow but “might” be more accurate)
• 1.2.5 Audio Description (Prerecorded): This one looks a lot like 1.2.3 A, but the difference here is that audio description is now required. Tools like Able Player make this easier
• 1.3.4 Orientation: Being able to switch orientations is required (e.g., portrait to landscape). To me, this is especially important on mobile, but you could make the argument it applies in responsive web page design

​

Section 1AA continued

• 1.3.5 Identify Input Purpose: You can identify the purpose of an input field. The easiest way to think about this is you should be able to determine if the field is for a name, address, or other things from the tags
• 1.4.3 Contrast (Minimum): Unless it’s part of a logo or is incidental, text needs to have a 4.5 contrast ratio. If large text, it needs to be 3 or greater.

Color Contrast Explained

• Color contrast is calculated through the Relative Luminance of the colors
• The luminance is calculated from the Red, Green, and Blue values of the color
• Red: 0.2126
• Green: 0.7152
• Blue: 0.0722
• Threshold equations then calculate luminance and then they are scaled between 1 and 21
• Realize what this means: the amount of green matters a lot, red much less so, and blue much less so, for the amount of luminance

Color Contrast Example

• The following is a screenshot of the Mac Accessibility Inspector
• The color contrast (difference in relative Luminance) of the text is 2.38
• Thoughts
• Do you find it hard to read?
• What about the colors makes it hard to read?
• Is it accessible according to 1.4.3?

Section 1AA continued

• 1.4.4 Resize Text: Generally, you want all of the text to be resizable. Modern web pages typically do this through responsive design
• 1.4.5 Images of Text: Just in general, use text instead of taking pictures of text. The reason is not just accessibility. It just breaks stuff. If you think you have a really good reason, you are probably wrong
• 1.4.10 Reflow: Only scroll in one dimension. Don’t make users scroll in two dimensions just to use the content

Section 1AA continued

• 1.4.11 Non-text contrast: If you use color in images, meet a 3 to 1 contrast ratio. This could apply for many things (e.g., charts, pictures). Note that the intentions are good here, but there are fundamental mathematical limitations to this requirement (e.g., charts that need N colors)
• 1.4.2 Text spacing: Changing the styling of the text should not change content
• 1.4.13 Content on Hover or Focus: This one is tricky, but basically if you are popping up content, you should be able to dismiss it with the keyboard and it shouldn’t disappear if you mouse over it

Section 2AA continued

• 2.4.5 Multiple Ways: Finding pages should be done through at least two of search, links, table of contents, site maps, or other techniques
• 2.4.6 Headings and Labels: These should describe the purpose. Note that this is important, but also very subjective
• 2.4.7 Focus Visible: The keyboard focus should be visible on the screen
• 2.4.11 Focus not Obscured (Minimum): Note: This is only in 2.2 Basically, don’t hide where the focus is at

​

Section 2AA continued

• 2.5.7 Dragging Movements: Note: This is only in 2.2 Using drag operations is fine, but it shouldn’t be the only way you can use content. A single pointer should be available as well
• 2.5.8 Target Size (Minimum): Note: This is only in 2.2 Target size for content should be a minimum of 24 CSS pixels, with some exceptions

Section 3AA

• 3.1.2 Language of Parts: If the human language of a page changes, you should be able to programmatically determine that for the pieces that change. If it is just one human language, that is ok (and an A standard)
• 3.2.3 Consistent Navigation: If you support navigation on pages, it should be similar for other pages
• 3.2.4 Consistent Identification: If a particular component works the same, it should be identified the same on each page
• 3.3.3 Error Suggestion: If the system can detect the reason for the error and it does not compromise something important (e.g., security) the error should be stated

Section 3AA continued

• 3.3.4 Error Prevention (Legal, Financial, Data): Note: This is only in 2.2 Legal documents require special rules. If you are writing pages with legal implications, look this up carefully
• 3.3.8 Accessible Authentication (Minimum): Note: This is only in 2.2 This one is new and interesting. They are basically trying to avoid forcing you to remember passwords or take cognitive tests to get into a webpage. Even though it isn’t legally required, I highly encourage following this. A few alternatives here:
• Allow for the use of password managers (e.g., Bitwarden, LastPass)
• Allow email authentication as an alternative

Section 4 AA

• 4.1.3 Status Messages: This is one is a bit tricky, but you can use roles like role = status or alert. You can also use aria-live regions, although in my view WCAG’s failure status doesn’t do a good job of discussing the pros and cons of these. For example:
• You may get different in-practice impacts with different approaches
• These impacts may vary by operating system and browser
• Screen reading and Braille devices in practice may vary a great deal in how they deal with the alternatives

Concluding Remarks

• While AAA is not discussed here, many of the recommendations are quite reasonable
• WCAG is helpful, but can be quite subjective
• It tends to tell you what not to do, but not tell you what “to” do
• Following WCAG hardly means you have created something useful or intuitive
• There are many hidden and poorly documented “gotchas” in this space. Perfect is the enemy of the good