Alex: Welcome back. Today we're using Appendix M as a practical reference for accessibility standards: WCAG 2.2, ARIA, and the checks that belong in a pull request review.

Jamie: I like the word reference there, because standards can feel huge. Are learners supposed to memorize criterion numbers?

Alex: No. The useful habit is knowing where to look when a review mentions something like WCAG 1.4.3 or name, role, value. This appendix pairs especially well with the open source culture chapter and the VS Code accessibility chapter, because it turns accessibility values into reviewable requirements.

Jamie: So when a maintainer says the focus indicator does not meet WCAG, I do not panic. I look up the criterion, understand the requirement, and check the change against it.

Alex: WCAG stands for Web Content Accessibility Guidelines. It is the main standard used to evaluate accessibility on the web, and WCAG 2.2 is organized around four principles, often remembered as POUR.

Jamie: Perceivable, Operable, Understandable, and Robust, right?

Alex: Right. Perceivable means people can access the information in a way that works for them, like an image having useful alt text. Operable means controls and navigation can actually be used, like a button working from the keyboard, not only on mouse hover. Understandable means the interface and messages make sense, such as an error that explains what needs fixing. Robust means the code can be interpreted reliably by browsers and assistive technologies.

Jamie: That last one is where custom widgets can get risky. Something may look like a menu or button visually, but if the code does not expose what it is, a screen reader may not have enough information.

Alex: Exactly. Every WCAG success criterion fits under one of those four principles. The learning cards in the appendix turn that into practical habits: use POUR while reviewing, use find to jump to criterion numbers, and keep contrast and ARIA pattern references close by.

Jamie: What about the levels? I see A, AA, and AAA in accessibility conversations, and I always wonder how much weight each one carries.

Alex: Level A is the baseline. It addresses severe barriers, such as missing keyboard access or missing text alternatives. Level AA goes further and is the usual target for compliance in government, enterprise, and many open source projects. Level AAA is the highest level, but it is not usually required across an entire project.

Jamie: So if I am filing a bug or reviewing a pull request, WCAG 2.2 AA is usually the level I should expect to work with.

Alex: Yes. If a project has its own policy, follow that, but AA is the standard you will most often cite. It is specific enough to guide a review without asking every project to meet every AAA requirement everywhere.

Alex: The criteria developers run into most often are not obscure. Under Perceivable, you will see non-text content, info and relationships, meaningful sequence, sensory characteristics, use of color, contrast, resize text, reflow, and non-text contrast.

Jamie: That is where low vision checks show up a lot. Text needs enough contrast, user interface parts need enough contrast, and content should still work at high zoom without forcing horizontal scrolling.

Alex: Exactly. Operable includes keyboard access, no keyboard traps, skip links or other ways to bypass repeated navigation, descriptive page titles, logical focus order, useful link text, clear headings and labels, visible focus, the WCAG 2.2 focus appearance requirement, and label in name.

Jamie: Label in name is the one where the accessible name should include the visible label, yes? So if a button visibly says Save, voice control and screen reader users should not get a totally different name.

Alex: Yes. Understandable includes the page language, no unexpected changes on focus or input, clear error identification, labels or instructions for form fields, and suggestions when an error can be corrected. Robust includes valid markup that assistive technology can interpret, name role value for interface components, and status messages that are announced without moving focus.

Jamie: That makes the criteria feel less like legal codes and more like review questions. Can I perceive it? Can I operate it? Can I understand it? Can assistive technology understand the code?

Alex: ARIA stands for Accessible Rich Internet Applications. It fills gaps when native HTML does not fully describe a complex interactive control.

Jamie: And ARIA has roles, states, and properties. Can you separate those in plain language?

Alex: A role says what the thing is, such as button, dialog, tab, navigation, or status. A state says what condition it is currently in, such as aria-expanded false, aria-checked true, or aria-disabled true. A property gives a stable detail, such as aria-label, aria-required, or aria-describedby.

Jamie: The part I hear people get wrong is assuming ARIA magically makes something accessible.

Alex: It does not. Use native HTML when it works, because a real button already has the right role and keyboard behavior. If you add an ARIA role to a custom element, you must also provide the matching keyboard interaction, like Enter and Space for a button. And ARIA changes what assistive technologies can read; it does not add visual styling or behavior by itself.

Jamie: Landmarks are another ARIA topic that comes up a lot for screen reader users. What are they doing?

Alex: Landmarks identify major page regions so someone can jump around efficiently. Common ones include banner for a site header, navigation for navigation links, main for the primary content, complementary for supporting content, contentinfo for a footer, search for search tools, form for an important form, and region for a named area that needs to be discoverable.

Jamie: So a page is not just a long stream of text and controls. It has named areas that can be navigated.

Alex: Yes. On GitHub and many web apps, screen reader users may move by landmarks using commands in NVDA, JAWS, or the VoiceOver Rotor. Good landmarks help someone move straight to the main content, the navigation, or a form without listening through everything in between.

Jamie: The appendix also shows common ARIA patterns. Let's talk through the ones a contributor is likely to touch.

Alex: First, the accessible button pattern when a native button cannot be used. You would need the button role, a keyboard focus target, a clear accessible name, and JavaScript support for Enter and Space. But the better question is always whether you can use a real button element instead.

Jamie: Then forms with errors. This one matters because error messages often get added late, and late fixes are where accessibility details disappear.

Alex: A good form field has a programmatic label, instructions when needed, and an error message connected to the field, often with aria-describedby. The field can use aria-invalid true when the value is invalid. The error text should say what is wrong and, when possible, how to fix it.

Jamie: Live regions are for updates that happen without a page reload, right? Like Saved, Item added, or Results loaded.

Alex: Yes. A polite live region, such as role status or aria-live polite, lets assistive technology announce the update without moving focus. Assertive announcements should be rare, because they interrupt what the person is already hearing. For expandable sections, the control should usually be a button with aria-expanded, often connected to the panel with aria-controls, and the state needs to change when the section opens or closes.

Jamie: That gives reviewers something concrete to inspect: the control, the name, the state, the keyboard behavior, and the announcement.

Jamie: Where do these standards show up in GitHub work? Not just building web apps, but actual contributions.

Alex: They show up when you file accessibility bugs, review pull requests, and write documentation. Standards help you describe the problem in a way maintainers can act on.

Jamie: For a bug report, what should I include?

Alex: Include the page or component, the steps to reproduce, what you expected, what actually happened, and the assistive technology or browser setup if it matters. If you know the relevant criterion, cite it. For example, a missing focus indicator might reference WCAG 2.4.7, and weak text contrast might reference WCAG 1.4.3.

Jamie: And in code review, I should not only ask whether the feature works visually.

Alex: Right. Review keyboard access, focus order, visible focus, contrast, form labels, error messages, status announcements, semantic HTML, and whether any ARIA used is actually needed and implemented correctly.

Jamie: Documentation has accessibility standards too, even if there is no widget involved.

Alex: Yes. Use clear headings, meaningful link text, useful alt text for images, plain instructions that do not rely only on color or position, and code examples that do not teach inaccessible patterns.

Jamie: Testing is where a lot of people either overtrust tools or feel like they have to test everything manually forever.

Alex: Automated tools are helpful, but they usually catch only about 30 to 40 percent of accessibility issues. They can flag missing alt text, some contrast failures, missing form labels, and certain ARIA mistakes. They cannot reliably tell whether alt text is meaningful, whether focus order feels logical, or whether an error message is actually helpful.

Jamie: So the remaining work is manual testing, but it can still be systematic.

Alex: Yes. Use the keyboard only. Check that focus is visible and moves in a sensible order. Zoom to 200 percent and 400 percent where relevant, check reflow, test contrast, listen with a screen reader when possible, and verify dynamic updates like saved messages or validation errors.

Jamie: The learning cards are useful here too. Different users will notice different risks first.

Alex: Exactly. Screen reader users may rely on find, landmarks, headings, and criterion numbers. Low vision users may focus on contrast, zoom, reflow, and readable tables. Sighted reviewers may scan examples and pattern demos, but still need to test with keyboard and structure, not just appearance.

Jamie: Before a pull request gets merged, what belongs on the accessibility checklist?

Alex: Check that images and icons have text alternatives when needed. Check that headings, lists, tables, and labels are coded as structure, not just styled to look that way. Check that color is not the only signal, contrast meets the relevant ratios, keyboard access works, focus order makes sense, focus is visible, status messages are announced, and ARIA is not being used to cover up avoidable HTML problems.

Jamie: And the review comment should include what was tested, not just a vague looks good.

Alex: Yes. A helpful review might say that keyboard navigation was tested, focus remained visible, form errors were announced, and contrast passed for the changed colors. If something fails, cite the criterion when you can and describe the user impact in plain language.

Jamie: For official references, the safest sources are the W3C WCAG 2.2 recommendation, WAI-ARIA 1.2, the WCAG Quick Reference, WAI tutorials, the ARIA Authoring Practices Guide, and tools like the WebAIM Contrast Checker.

Alex: That is also why the appendix connects each topic back to authoritative references. You do not have to carry the whole standard in your head. You need to know how to connect a real contribution, a real test result, and the standard that explains why the fix matters.