Accessibility with WCAG 2.2

Since lesson 2.1.2, you’ve been building the Kladde so that everybody can use it: headings in order, landmarks, a label on every field, error messages as text, a visible focus. So far that happened by rules you got to know piece by piece. This lesson brings the framework behind them: the Web Content Accessibility Guidelines (WCAG) 2.2, the W3C’s standard for accessible web content. And you learn to check a page the way people do who depend on accessibility: with the keyboard alone, with a screen reader and with tools that find some of the defects automatically.

At the end, there’s a check report for the Kladde in docs/accessibility.md. From now on, every pull request that changes a page checks it by the same procedure.

Who needs accessibility

Accessibility means: A page works for people with very different needs. Some examples:

• Blind people listen to the page with a screen reader, a program that reads aloud what’s on the screen and is controlled with the keyboard. They need alternative texts, headings, landmarks and labels.
• People with low vision magnify the page a lot or set a larger font. They need enough contrast and a page that doesn’t slide sideways at 400 percent zoom.
• People with a color vision deficiency, about one in twelve men, have trouble telling red and green apart. An error message that consists only of a red border is something they don’t see.
• People who can’t use a mouse, for example because of paralysis or a tremor, operate everything with the keyboard, with voice control or with a single switch. They need a page that can be operated completely with the keyboard.
• People with cognitive impairments need clear language, unambiguous labels and error messages that say what to do.

On top of that come situations in which it’s like that for everyone: sun on the phone, an arm in a cast, a loud train without headphones. So accessibility doesn’t help only a small group. A page that works with the keyboard usually also has a clear order, and a page with good contrast is easier for everybody to read.

WCAG 2.2 in brief

WCAG 2.2 is a W3C recommendation. It sorts its requirements under four principles:

Below the principles are guidelines, and below them the actual success criteria. Each has a number, an English name and a level:

• A is the minimum. Whoever misses an A criterion shuts people out completely, for example with a button the keyboard can’t reach.
• AA is the usual target. Laws and standards refer to this level. “Conformant to level AA” means: all criteria of levels A and AA are met.
• AAA goes further, for example with a contrast of 7:1. The W3C itself advises against requiring AAA for entire websites, because not all content can be designed that way.

The Kladde’s target is WCAG 2.2, level AA. That’s been in the house rules since K2. These criteria affect the Kladde most:

New in version 2.2 are, among others, 2.4.11 and 2.5.8 from this table, plus criteria for help in the same place, for information you don’t have to enter twice, and for sign-ins without puzzles. The old criterion 4.1.1 “Parsing” was dropped because browsers now repair broken HTML uniformly. You still need the validator from lesson 2.1.2: Valid HTML is the foundation on which everything else builds.

For each criterion, read the W3C’s “Understanding” page when you need to (link at the end). It says what’s meant, why, and with which techniques you meet it.

Keyboard and visible focus

With the keyboard, you operate a page with a few keys:

Five rules follow:

1. Everything you can click is also reached and operated with the keyboard (2.1.1). Links, buttons and form fields can do that by themselves. A div with a click event can’t. That’s why you always take the fitting element.
2. The focus follows the order in the source (2.4.3). If CSS arranges the elements differently, for example with order or grid, the focus seems to jump back and forth wildly. Never set a tabindex greater than 0. It sends the element to the start of the order, before everything else. Only self-built controls need tabindex="0", and you avoid those. tabindex="-1" makes an element focusable by script without putting it into the Tab order; that comes up in module 2.5.
3. Trapped nowhere (2.1.2). You get out of every element with Tab or Esc.
4. The focus is always visible (2.4.7) and not hidden (2.4.11), for example by a fixed header that stays put while scrolling. Since lesson 2.1.4, the Kladde draws a three-pixel-wide ring around the element with the focus. outline: none without a replacement is the defect you’ll look for in exercise 2.
5. Targets are large enough (2.5.8): at least 24 by 24 CSS pixels, or smaller with so much spacing that a circle of 24 pixels around each target touches no other. The Kladde’s navigation links are a good 40 pixels tall thanks to padding. Its radio buttons are only 20 pixels in size but stand 32 pixels apart, and their label also checks them when clicked.

A page often consists of blocks that return on every page: logo and navigation. Anyone working with the keyboard has to press Tab four times on every page of the Kladde before reaching the content. For screen readers, landmarks and headings are enough to skip this block (2.4.1). Anyone working with the keyboard without a screen reader gets nothing from that. For them there’s the skip link: a link “Skip to content” as the first element of the page, which only becomes visible when it has the focus and points to the main. The Kladde gets it in module 2.5 with its layout, because there the header is in one single place instead of four files.

Contrast and color

Text has to stand out from the background. WCAG measures that with the contrast ratio of two colors: from 1:1 (same color) to 21:1 (black on white). Required are:

• 4.5:1 for text (1.4.3), 3:1 for large text: from 24 pixels, or from just under 19 pixels in bold. Exempt are text in a logo, pure decoration and disabled controls.
• 3:1 for controls and graphics (1.4.11): the border of an input field against its surroundings, the focus ring, an icon that means something. A divider that only structures doesn’t count.
• Color never alone (1.4.1): A link in running text is also underlined, an error also has a text.

You calculate the ratio from the relative luminance L of both colors: (lighter L + 0.05) / (darker L + 0.05). Luminance weights red, green and blue the way the eye perceives them; green counts most. The following program calculates it, as announced in lesson 2.1.4. Create contrast.cs in your practice folder k2-practice:

// contrast.cs: calculates contrast ratios according to WCAG 2.2
using System.Globalization;

if (args.Length == 2)
{
    double ratio = Contrast.Ratio(args[0], args[1]);
    Console.WriteLine($"{args[0]} on {args[1]}: {Contrast.Format(ratio)}");
    Console.WriteLine($"  Text (at least 4.5:1):                      {(ratio >= 4.5 ? "met" : "too low")}");
    Console.WriteLine($"  large text, controls (at least 3:1):        {(ratio >= 3 ? "met" : "too low")}");
    return 0;
}

if (args.Length == 1 && File.Exists(args[0]))
{
    int failures = 0;
    foreach (string line in File.ReadAllLines(args[0]))
    {
        if (line.Trim().Length == 0 || line.TrimStart().StartsWith("//"))
        {
            continue;
        }

        string[] parts = line.Split(';', StringSplitOptions.TrimEntries);
        double ratio = Contrast.Ratio(parts[1], parts[2]);
        double required = double.Parse(parts[3], CultureInfo.InvariantCulture);
        bool ok = ratio >= required;
        if (!ok) failures++;
        Console.WriteLine($"{(ok ? "ok  " : "LOW ")} {Contrast.Format(ratio),8} (min. {required.ToString("0.0", CultureInfo.GetCultureInfo("en-US"))}:1)  {parts[0]}");
    }

    Console.WriteLine(failures == 0 ? "All pairs meet their minimum." : $"{failures} pair(s) below the minimum.");
    return failures == 0 ? 0 : 1;
}

Console.WriteLine("Usage: dotnet run contrast.cs -- <foreground> <background>   (e.g. 4a5552 fbfaf7)");
Console.WriteLine("       dotnet run contrast.cs -- <file>   (per line: name; foreground; background; minimum)");
return 2;

static class Contrast
{
    // The contrast ratio according to WCAG: (lighter luminance + 0.05) / (darker luminance + 0.05), from 1:1 to 21:1.
    public static double Ratio(string foreground, string background)
    {
        double a = Luminance(foreground);
        double b = Luminance(background);
        return (Math.Max(a, b) + 0.05) / (Math.Min(a, b) + 0.05);
    }

    // Rounded down, never up: 4.499 is not a 4.5.
    public static string Format(double ratio) =>
        (Math.Floor(ratio * 100) / 100).ToString("0.00", CultureInfo.GetCultureInfo("en-US")) + ":1";

    // The relative luminance of a color like 1f5f5b or #1f5f5b, from 0 (black) to 1 (white).
    private static double Luminance(string color)
    {
        string hex = color.TrimStart('#');
        if (hex.Length != 6)
        {
            throw new FormatException($"Not a color with six digits: {color}");
        }

        double r = Channel(hex[0..2]);
        double g = Channel(hex[2..4]);
        double b = Channel(hex[4..6]);
        return 0.2126 * r + 0.7152 * g + 0.0722 * b;
    }

    private static double Channel(string pair)
    {
        double c = int.Parse(pair, NumberStyles.HexNumber, CultureInfo.InvariantCulture) / 255.0;
        return c <= 0.04045 ? c / 12.92 : Math.Pow((c + 0.055) / 1.055, 2.4);
    }
}

Only the class at the end is new: A file-based app may contain its own types after the top-level statements. Channel converts a color value from 0 to 255 into its linear share, as WCAG prescribes. Try the Kladde’s muted text on its surface:

dotnet run contrast.cs -- 4a5552 fbfaf7

4a5552 on fbfaf7: 7.41:1
  Text (at least 4.5:1):                      met
  large text, controls (at least 3:1):        met

Leave off the # in front of the colors. In PowerShell and in bash, a # starts a comment, and the rest of the line wouldn’t even reach the program. With a file as the argument, the program checks many pairs at once and ends with exit code 1 as soon as one is too low. That way it fits into a check script, like outline.cs from lesson 2.1.2.

The browser helps too: In the DevTools, the color picker in Styles shows the contrast ratio next to every text color, and the Inspect tool shows it in the overlay as soon as you point at a text. Under Rendering, “Emulate vision deficiencies” shows the page the way people with a color vision deficiency see it, for example with no color at all (“Achromatopsia”).

Name, role and state

A screen reader doesn’t read the page’s pixels. It asks the browser, and the browser builds a second tree from the DOM, the accessibility tree. In it, every element that means something has three things:

• a role: link, button, input field, heading of level 2, table;
• a name: the text of a link, the label of a field, the alternative text of an image;
• states and properties: checked, required, invalid, current page.

From these three comes what the screen reader says: “Email, edit, required, We’ll send the confirmation to this address.” That’s criterion 4.1.2. In Edge, you see the tree in Elements on the Accessibility tab next to Styles: at the top the element’s position in the tree, below it under Computed Properties name, role and states. An element with the role generic and no name that you’re supposed to click anyway is immediately recognizable there as a problem.

The name comes from fixed sources, in a fixed order: aria-labelledby, aria-label, then the fitting HTML (a field’s label, the content of a link or button, an image’s alt), finally title and, for fields, the placeholder. That has a consequence you’ll see in exercise 2: A field with a placeholder and without a label has a name for the browser. The screen reader reads it aloud, and the automated check reports nothing. But a sighted person loses the label as soon as they type (3.3.2).

ARIA only where HTML isn’t enough

ARIA (Accessible Rich Internet Applications) is a W3C addition to HTML. With attributes like role, aria-label or aria-invalid, it changes what’s in the accessibility tree. You already know four of them. The first rule from the W3C’s guide to using ARIA reads, roughly: If there’s an HTML element or attribute that already brings the meaning and behavior, use that instead of reinterpreting another element with ARIA.

This comparison shows why:

<!-- not like this -->
<div class="button" role="button">Save</div>

<!-- like this -->
<button type="submit">Save</button>

role="button" tells the screen reader “button”. That’s all it does: The div gets no focus, Enter and Space trigger nothing, and without script it doesn’t submit a form either. A button can do all of that by itself. ARIA only changes what is said, never what happens. Three more rules follow:

• No ARIA is better than wrong ARIA. A wrong role or a forgotten state misleads people who rely on it.
• aria-label replaces the visible text for assistive technologies. If it deviates from it, voice input no longer understands “Click Save” if the button is called “Back up data” for assistive technologies.
• aria-hidden="true" never on anything that can receive the focus. The element is then invisible to the screen reader, but the keyboard lands on it anyway.

The Kladde uses ARIA exactly where HTML has nothing of its own:

In module 2.2, aria-live is added, with which a script has a change announced.

Checking in four ways

No single check finds everything. That’s why you check every page in four ways, and in this order: What the keyboard and the screen reader show is what people experience. The tools then find what’s easy to overlook.

With the keyboard

The keyboard check from the definition of done, now in detail. Put the mouse away and reload the page:

1. Press Tab until you’re back at the top in the address bar. Does the focus stop at every link, every field and every button? Is it clearly visible at every stop?
2. Is the order the reading order: header, navigation, content from top to bottom, footer?
3. Can you get all the way back with Shift+Tab without getting stuck anywhere?
4. Trigger every element: links with Enter, buttons with Enter and Space, checkboxes with Space, a group of radio buttons with the arrow keys. By the way, a group is only a single stop; inside it, the arrows choose.
5. Fill out every form completely once and submit it.
6. Zoom in with Ctrl and plus to 400 percent. In a window of 1280 pixels, that’s 320 CSS pixels (1.4.10). Is everything still there, with no horizontal scrolling?

Depending on the browser, a date field can have several stops, one each for day, month and year. That isn’t a defect of the page.

With a screen reader

On Windows, Narrator is already built in; for free, NVDA is added, a free screen reader that many blind people use. On the Mac, it’s VoiceOver, best with Safari. The most important commands:

With Shift, the letters jump backward instead of forward. You switch Narrator’s scan mode with the special key and Space; in Edge it’s usually already on. In an input field, it switches itself off so that the letters go into the field instead of jumping.

The first attempt feels confusing. Set the speaking rate slower and try it first with a page you know. While checking, pay attention to these questions: Is the page’s title read first? Do the headings, as a list, make a table of contents? Does every field say its label, its kind and whether it’s required? On an error page, do you hear that something is wrong, and what? Is the screen reader silent for decorative images?

With the Edge DevTools

You know the DevTools from lesson 2.1.5. For accessibility, five places count:

• Issues (via the Command Menu): In the Accessibility section are, among other things, missing alternative texts, fields without labels and too little contrast.
• Elements, Accessibility tab: accessibility tree, ARIA attributes, name and role; plus the Source Order Viewer, which lays the order in the source over the page as numbers.
• Inspect (Ctrl+Shift+C): When you point at an element, the overlay names under Accessibility the contrast, name, role and whether the keyboard reaches it.
• Rendering: simulate color vision deficiencies and the dark scheme with “Emulate CSS media feature prefers-color-scheme”.
• Lighthouse with the category Accessibility: a report with a score and the defects found, more on that in lesson 2.1.8.

With Accessibility Insights for Web

Accessibility Insights for Web is a free extension from Microsoft for Edge and Chrome. You install it from your browser’s add-on store and open it on a page via its icon or with Alt+Shift+K. For every pull request, FastPass is enough:

1. Automated checks check the page against dozens of rules. Behind it is axe-core, a free library for such checks, the same one Lighthouse uses.
2. Tab stops: You go through the page with Tab, and the tool draws every stop with a number and a line. Missing stops and traps stand out that way.
3. Needs review: Places the automation can’t decide, you decide.

For a complete check, there’s the Assessment, which leads step by step through all the requirements. It takes hours and belongs at the end of a milestone, not in every pull request.

What the automation finds and what it doesn’t

Automated checks reliably find what can be read off the code: an image without alt, a field without any name, too little contrast in text, a missing lang, a duplicate id, a button without a name. They don’t find:

• whether an alternative text or a label fits;
• whether the focus can be seen and the order makes sense;
• whether an error message helps or just says “Invalid”;
• whether information is conveyed only through color;
• whether the page, read aloud, is understandable.

The Accessibility Insights documentation says it itself: Most problems are found only by a manual check. A green automated check is therefore necessary but never enough.

When accessibility is mandatory

This section is an overview, not legal advice. Public bodies have to make their websites and apps accessible; in Germany, for the federal government that’s regulated by the Disability Equality Act (BGG) and the BITV 2.0, for the states and municipalities by laws of their own. For companies, the Barrierefreiheitsstärkungsgesetz (BFSG, the German accessibility act) has applied since June 28, 2025. It implements an EU directive, the European Accessibility Act, and covers certain products and services for consumers, including e-commerce services. Microenterprises that offer services are exempt. The European standard EN 301 549, on which such rules for web content are based, requires the WCAG success criteria at level AA: the older version V3.2.1 those of WCAG 2.1, the new version V4.1.1 those of WCAG 2.2. Whoever meets WCAG 2.2 AA thereby also meets the older version. Whether and how an obligation applies to a particular offering and which version counts for it is a legal question that legal advice settles.

// Kladde, light scheme: text needs 4.5, controls and focus 3
Text on surface;                  1d2422; fbfaf7; 4.5
Text on card and field;           1d2422; ffffff; 4.5
Muted text on surface;            4a5552; fbfaf7; 4.5

// Kladde, light scheme: text needs 4.5, controls and focus 3
Text on surface;                  1d2422; fbfaf7; 4.5
Text on card and field;           1d2422; ffffff; 4.5
Muted text on surface;            4a5552; fbfaf7; 4.5
Link on surface;                  1a5c8a; fbfaf7; 4.5
Link on card;                     1a5c8a; ffffff; 4.5
Error text on surface;            a4262c; fbfaf7; 4.5
Text on the button;               ffffff; 1f5f5b; 4.5
Border of a field;                4a5552; ffffff; 3
Error border of a field;          a4262c; ffffff; 3
Focus ring on surface;            b35c00; fbfaf7; 3
Focus ring on card;               b35c00; ffffff; 3
Button on surface;                1f5f5b; fbfaf7; 3

// Kladde, dark scheme
Text on surface;                  e6ebe9; 141a19; 4.5
Text on card and field;           e6ebe9; 1d2524; 4.5
Muted text on surface;            b4bfbb; 141a19; 4.5
Link on surface;                  8cc4f0; 141a19; 4.5
Link on card;                     8cc4f0; 1d2524; 4.5
Error text on surface;            ff8a8f; 141a19; 4.5
Text on the button;               0d1413; 7cc4bd; 4.5
Border of a field;                b4bfbb; 1d2524; 3
Error border of a field;          ff8a8f; 1d2524; 3
Focus ring on surface;            ffb366; 141a19; 3
Focus ring on card;               ffb366; 1d2524; 3
Button on surface;                7cc4bd; 141a19; 3

ok    15.15:1 (min. 4.5:1)  Text on surface
ok    15.81:1 (min. 4.5:1)  Text on card and field
ok     7.41:1 (min. 4.5:1)  Muted text on surface
ok     6.83:1 (min. 4.5:1)  Link on surface
ok     7.13:1 (min. 4.5:1)  Link on card
ok     6.95:1 (min. 4.5:1)  Error text on surface
ok     7.37:1 (min. 4.5:1)  Text on the button
ok     7.74:1 (min. 3.0:1)  Border of a field
ok     7.26:1 (min. 3.0:1)  Error border of a field
ok     4.52:1 (min. 3.0:1)  Focus ring on surface
ok     4.72:1 (min. 3.0:1)  Focus ring on card
ok     7.06:1 (min. 3.0:1)  Button on surface
ok    14.62:1 (min. 4.5:1)  Text on surface
ok    12.98:1 (min. 4.5:1)  Text on card and field
ok     9.32:1 (min. 4.5:1)  Muted text on surface
ok     9.45:1 (min. 4.5:1)  Link on surface
ok     8.39:1 (min. 4.5:1)  Link on card
ok     7.79:1 (min. 4.5:1)  Error text on surface
ok     9.30:1 (min. 4.5:1)  Text on the button
ok     8.27:1 (min. 3.0:1)  Border of a field
ok     6.91:1 (min. 3.0:1)  Error border of a field
ok     9.98:1 (min. 3.0:1)  Focus ring on surface
ok     8.85:1 (min. 3.0:1)  Focus ring on card
ok     8.80:1 (min. 3.0:1)  Button on surface
All pairs meet their minimum.

// barriers.cs: a page with five barriers, to find with keyboard, screen reader and a checking tool
#:sdk Microsoft.NET.Sdk.Web
#:property PublishAot=false

using System.Net;

var builder = WebApplication.CreateBuilder();
builder.Logging.SetMinimumLevel(LogLevel.Warning);
var app = builder.Build();

const string Css = """
    *, *::before, *::after { box-sizing: border-box; }

    body {
      margin: 0;
      font-family: system-ui, "Segoe UI", Roboto, sans-serif;
      line-height: 1.5;
      color: #1d2422;
      background: #ffffff;
    }

    :focus { outline: none; }

    .site-header { padding: 1rem; border-bottom: 1px solid #c9cfcc; }
    .site-header a { color: #1a5c8a; font-weight: 700; }
    main { max-width: 40rem; margin: 0 auto; padding: 1.5rem 1rem; }
    .hint { color: #9aa19e; }
    .field { margin-bottom: 1rem; }
    .field label { display: block; margin-bottom: 0.25rem; font-weight: 600; }

    .field input {
      width: 100%;
      padding: 0.5rem;
      font: inherit;
      border: 1px solid #4a5552;
      border-radius: 0.375rem;
    }

    .field .invalid { border: 2px solid #a4262c; }

    button {
      display: inline-flex;
      padding: 0.5rem 1.5rem;
      color: #ffffff;
      background: #1f5f5b;
      border: 0;
      border-radius: 0.375rem;
      cursor: pointer;
    }
    """;

app.MapGet("/", () => Html(Page(name: "", phone: "", nameMissing: false)));
app.MapGet("/barriers.css", () => Results.Content(Css, "text/css; charset=utf-8"));

app.MapPost("/callback", async (HttpRequest request, HttpResponse response) =>
{
    var form = await request.ReadFormAsync();
    string name = form["name"].ToString().Trim();
    string phone = form["phone"].ToString().Trim();
    if (name.Length == 0)
    {
        return Html(Page(name, phone, nameMissing: true), StatusCodes.Status400BadRequest);
    }

    response.Headers.Location = "/thanks";
    return Results.StatusCode(StatusCodes.Status303SeeOther);
});

app.MapGet("/thanks", () => Html("""
    <!doctype html>
    <html lang="en">
    <head>
      <meta charset="utf-8">
      <meta name="viewport" content="width=device-width, initial-scale=1">
      <title>Thanks – Kladde</title>
      <link rel="stylesheet" href="/barriers.css">
    </head>
    <body>
      <main>
        <h1>Thanks</h1>
        <p>We’ll call you back. <a href="/">Arrange another callback</a></p>
      </main>
    </body>
    </html>
    """));

Console.WriteLine("The page with the barriers is running on http://localhost:5080. Quit with Ctrl+C.");
app.Run("http://localhost:5080");

static IResult Html(string html, int status = StatusCodes.Status200OK) =>
    Results.Content(html, "text/html; charset=utf-8", statusCode: status);

// The page with the form; the input comes back encoded into the fields.
static string Page(string name, string phone, bool nameMissing) => $$"""
    <!doctype html>
    <html lang="en">
    <head>
      <meta charset="utf-8">
      <meta name="viewport" content="width=device-width, initial-scale=1">
      <title>Arrange a callback – Kladde</title>
      <link rel="stylesheet" href="/barriers.css">
    </head>
    <body>
      <header class="site-header">
        <a href="/">Kladde</a>
      </header>
      <main>
        <h1>Arrange a callback</h1>
        <p class="hint">We call back on weekdays between 9:00 and 17:00.</p>
        <form action="/callback" method="post">
          <div class="field">
            <label for="name">Name</label>
            <input type="text" id="name" name="name" autocomplete="name" value="{{WebUtility.HtmlEncode(name)}}"{{(nameMissing ? " class=\"invalid\"" : "")}}>
          </div>
          <div class="field">
            <input type="tel" id="phone" name="phone" autocomplete="tel" placeholder="Phone number" value="{{WebUtility.HtmlEncode(phone)}}">
          </div>
          <button type="submit">
            <svg width="24" height="24" viewBox="0 0 24 24"><path d="M4 12h14m-6-6 6 6-6 6" fill="none" stroke="currentColor" stroke-width="2"/></svg>
          </button>
        </form>
      </main>
    </body>
    </html>
    """;

:focus-visible { outline: 3px solid #b35c00; outline-offset: 2px; }

.hint { color: #4a5552; }

.field [aria-invalid="true"] { border: 2px solid #a4262c; }
.field-error { margin: 0.25rem 0 0; color: #a4262c; font-weight: 700; }

button {
  display: inline-flex;
  align-items: center;
  gap: 0.5rem;
  font: inherit;
  font-weight: 700;
  padding: 0.5rem 1.5rem;
  color: #ffffff;
  background: #1f5f5b;
  border: 0;
  border-radius: 0.375rem;
  cursor: pointer;
}

// The page with the form; the input comes back encoded into the fields.
static string Page(string name, string phone, bool nameMissing)
{
    string title = nameMissing ? "Error: Arrange a callback – Kladde" : "Arrange a callback – Kladde";
    string nameState = nameMissing ? " aria-invalid=\"true\" aria-describedby=\"name-error\"" : "";
    string nameError = nameMissing ? "<p class=\"field-error\" id=\"name-error\">Please enter your name.</p>" : "";
    return $$"""
        <!doctype html>
        <html lang="en">
        <head>
          <meta charset="utf-8">
          <meta name="viewport" content="width=device-width, initial-scale=1">
          <title>{{title}}</title>
          <link rel="stylesheet" href="/barriers.css">
        </head>
        <body>
          <header class="site-header">
            <a href="/">Kladde</a>
          </header>
          <main>
            <h1>Arrange a callback</h1>
            <p class="hint">We call back on weekdays between 9:00 and 17:00.</p>
            <form action="/callback" method="post">
              <div class="field">
                <label for="name">Name</label>
                <input type="text" id="name" name="name" autocomplete="name" value="{{WebUtility.HtmlEncode(name)}}"{{nameState}}>
                {{nameError}}
              </div>
              <div class="field">
                <label for="phone">Phone (optional)</label>
                <input type="tel" id="phone" name="phone" autocomplete="tel" value="{{WebUtility.HtmlEncode(phone)}}">
              </div>
              <button type="submit">
                Request callback
                <svg aria-hidden="true" width="24" height="24" viewBox="0 0 24 24"><path d="M4 12h14m-6-6 6 6-6 6" fill="none" stroke="currentColor" stroke-width="2"/></svg>
              </button>
            </form>
          </main>
        </body>
        </html>
        """;
}

# Accessibility of the Kladde

Target: WCAG 2.2, level AA. Every pull request that changes a page checks that page
by the procedure below. A complete check (Accessibility Insights, Assessment)
follows at the end of every milestone.

## Procedure
1. Keyboard check: all stops with Tab and Shift+Tab, focus always visible,
   everything triggered with Enter or Space, trapped nowhere, 400 percent without
   horizontal scrolling.
2. Screen reader (Narrator, NVDA or VoiceOver): title, headings,
   landmarks, every field with label, kind and requirement, error page.
3. Accessibility Insights FastPass in the light and in the dark scheme.
4. dotnet run contrast.cs -- contrasts.txt ends with exit code 0.

## Check of the prototype
Checked on: <date>, by: <name>, with: Edge, Narrator, Accessibility Insights for Web
Pages: index.html, contacts.html, appointment.html, appointment-error.html

| Way | Result |
| --- | --- |
| Keyboard | passed on all four pages |
| Screen reader | passed |
| FastPass light and dark | no findings |
| Contrasts | 24 pairs, all met |

## Findings and fix
| Finding | Criterion | Fix |
| --- | --- | --- |
| (your findings, one line each; none: "none") | | |

## Open
- Four Tab stops lie before the content (logo, three links). With landmarks and
  headings, 2.4.1 is met; a skip link comes with the layout in module 2.5.
- The date field has several Tab stops depending on the browser. Not a defect of the page.

- Accessibility Insights FastPass reports nothing on every new or changed page,
  in the light and in the dark scheme. Procedure: docs/accessibility.md

The Kladde

After this lesson, the prototype has been checked against WCAG 2.2 AA: with no finding from the automated check, with a passed keyboard check and a check report that every later pull request can refer to. In module 2.5, the pages become Blazor components. The rules of this lesson come along: The check procedure stays the same, and in lesson 2.5.13 you check the finished pages once more.

What you can do now

• You explain the four principles of WCAG, the levels A, AA and AAA and why the Kladde aims for AA.
• You operate a page with the keyboard alone and recognize missing focus, a wrong order and traps.
• You recalculate contrasts, tell 4.5:1 for text from 3:1 for controls and never let color speak alone.
• You read name, role and state in the accessibility tree and use ARIA only where HTML has nothing of its own.
• You operate a page with a screen reader and check it with the Edge DevTools and Accessibility Insights for Web.
• You know that the automation finds only some of the defects, and you record a check in a report.

Read more

• Learn the basics of web accessibility: the Microsoft Learn module on tools and design for accessibility.
• Accessibility-testing features: which of the Edge DevTools’ tools check which part of accessibility, with a demo page for practice.
• Test accessibility using the Accessibility tab: accessibility tree, ARIA attributes and computed properties.
• Accessibility Insights for Web: FastPass and Assessment, with installation instructions.
• WCAG 2.2 and Understanding WCAG 2.2 at the W3C: the standard and, for every criterion, the explanation.
• Using ARIA at the W3C: the rules for ARIA, including the first one.
• NVDA: the free screen reader for Windows.