By the end of the lesson, you can explain why accessibility is not the concern of a narrow group, you know the four principles (POUR) and levels of WCAG, you can calculate the contrast ratio of a text–background color pair, and you know how to write alternative text for an image.
Why do we talk about this in a web course?
A university course-registration page is used by many kinds of people. One student is color-blind, so cannot see the red error message. Another works with a keyboard only for a few weeks because of a hand injury. A third watches the video briefing on a noisy train, so wants captions. A fourth tries to read the page on a slow, old phone in strong sunlight. The problem is not that these people use the system in "abnormal" circumstances, but that the system was built for an imagined user who works with a mouse, has good eyesight, and sits on a fast network.
The original promise of the web was that information is reachable regardless of device and place (1.1). Accessibility makes this promise serious: the content and the functions can be used by as many people as possible, in as many situations as possible. There are business, legal, and ethical reasons for it too, but from a developer's viewpoint the simplest reason is that a service fulfils its task only if its target audience can really use it.
Inclusive design emphasizes that we should not try to fix the system at the end for a narrow group, but already at design time ask: who can be left out of this decision? A real button is focusable and keyboard-activatable by default; fixing a clickable div afterwards brings along many forgotten details (see 9.2).
Barriers: it is not only about disability
Permanent: a blind or low-vision person uses a screen reader, a deaf user needs captions, a person with a motor impairment does not necessarily use a mouse.
Temporary: a broken arm, an eye procedure, a migraine, a temporary hearing problem.
Situational: in sunlight the display's contrast is weak, the user is holding a baby, or cannot turn on the sound of a video in a library.
That is why it is useful to think along the "spectrum of abilities". Captions are indispensable for a deaf user, but they also help many other people when learning a language or watching a video without sound. A good heading structure is a navigation tool for those working with a screen reader, but it gives everyone more scannable content.
flowchart LR
C[Content] --> P[Perceivable]
C --> K[Operable]
C --> E[Understandable]
C --> M[Robust]
The WCAG approach: POUR
WCAG (Web Content Accessibility Guidelines) is the web accessibility guideline of the W3C (1.2). According to the W3C's page the current version is WCAG 2.2: it does not supersede 2.1 and 2.0 but is backward compatible, meaning that content conforming to 2.2 also conforms to the earlier ones. WCAG 2.2 declared a single earlier requirement, 4.1.1 Parsing, obsolete. WCAG 3 is still an early draft. The guideline is not a checklist spell but a thinking framework. Its four principles can be remembered by the acronym POUR:
Principle
Question
Example
Perceivable
Can the user take in the information?
Alternative text for an image, captions for a video, enough contrast.
Operable
Can every function be operated without a mouse?
Keyboard access, visible focus, logical order.
Understandable
Are the language and the behavior understandable?
Labeled fields, an error message that says what is wrong and how it can be fixed.
Robust
Can it be interpreted in different browsers and with assistive technologies?
Standard, semantic HTML (9.2).
The error message example: "Invalid data" is no help; "The email address is missing the @ sign" is.
Levels
WCAG expresses conformance in the levels A, AA, and AAA. In practice the AA level is a common goal. The point, however, is not the "sticker": a formally conforming page can also be hard to use if we have not tried the real user tasks.
Some requirements of the WCAG 2.2 AA level that are also touched on in this course:
Contrast (1.4.3): the contrast ratio of normal text to the background is at least 4.5:1, for large text at least 3:1.
Non-text contrast (1.4.11): user interface elements and graphics needed for information have a contrast of at least 3:1 against adjacent colors.
Target size (2.5.8, new in 2.2): targets touched with a pointing device (finger, mouse) are at least 24×24 CSS pixels, with the exceptions listed in the specification (for example enough spacing or inline text).
Focus not obscured (2.4.11, new in 2.2): an element focused with the keyboard must not be completely covered by another element (for example a fixed header).
Contrast, color, and readability
The contrast ratio expresses how well the text separates from the background: it is calculated from the ratio of the relative luminance of two colors, between 1:1 (the same color) and 21:1 (black–white). This is not a matter of taste: on a weak display, with tired eyes, or in strong light even a sighted user can lose the information. Calculated by the WCAG formula, on a white background:
Text color
Contrast ratio
4.5:1 (normal text)
3:1 (large text, interface element)
#aaaaaa (pale gray)
2.32:1
does not meet
does not meet
#767676
4.54:1
meets (just)
meets
#595959
7.00:1
meets
meets
#17365d (dark blue)
12.19:1
meets
meets
#ff0000 (red)
4.00:1
does not meet
meets
(We calculated the values in Node.js with the WCAG relative luminance formula.) The red example is instructive: the same color is fine for a large heading, but not for body text.
Alternative text: describe the meaning of the image
The alt attribute is not for repeating the file name. A chart-final-v2.png tells nothing to a screen reader. The alternative text conveys the role the image plays in the given context.
Image
Good alternative text
Why?
A product photo in a catalogue
alt="Blue backpack, front view"
It describes what is essential in the image.
A chart that complements the text of an article
alt="The number of registrations grows steadily from January to June"
It summarizes the main message; the details are in the text.
A purely decorative image
alt=""
Empty alt: the screen reader skips it, it does not burden with noise.
A complex diagram
a short alt + a detailed description in the text
The short text is not enough to convey all the data.
With a missing alt, assistive technology does not know whether the image is decorative, so it may bring noise into the reading by announcing the image or reading out the file name; an empty alt, by contrast, is a clear signal: this image carries no information. In the next lesson we will see that the automatic checker notices a missing alt, but cannot judge whether the text of the alt is meaningful.
Worked example: a fixed event page in Kurzuspont
On the page of a faculty lecture in Kurzuspont, the time appears next to a tiny calendar icon, the enrolment is a colorful box labeled "Click here!", and the venue is shown on an embedded map. In a more inclusive version the page is structured with real headings; the time is readable as text too; the enrolment is a real, clearly labeled button or link ("Enrol for the lecture of 18 September"); below the map there is a text address and route information; the contrast of the text is at least 4.5:1.
We did not make a separate "page for the blind". We made the same page more understandable for everyone. This is the typical pattern of good accessibility decisions.
How do we start in practice?
Fixing an existing page is best started with the most important user paths: can the information be found, can the main operation be started, can the form be submitted? A simple manual test: go through the page with the Tab key, zoom in the browser, turn off the sound of a video, and see whether the interface remains understandable. Automated checkers are quick, but their findings must be interpreted with human judgment (9.2).
Accessibility should not be a single checking day at the end of a project. When designing a new component, the team can immediately decide on the appropriate HTML element, the focus state, the error messages, and the small-screen behavior; this way fewer later fixes are needed.
Common misconceptions
Statement
Clarification
"Accessibility matters only for blind users."
Vision, hearing, movement, attention, language, device, and environment can all affect use.
"An automatic checking tool tells everything."
It cannot judge whether an alternative text is meaningful or a flow is understandable.
"Meeting the AA level is enough for usability."
The level is the minimum; real tasks must be tried.
"Accessibility limits creativity."
It gives a frame: the look is good if it is also clear, operable, and stable.
"Pale gray is elegant."
Text with a 2.3:1 contrast is unreadable for many people.
In brief
Accessibility is the usability of content and functions for as many people and situations as possible; a barrier can be permanent, temporary, or situational.
The four principles of WCAG 2.2: perceivable, operable, understandable, robust (POUR); its levels are A, AA, AAA.
Normal text needs a contrast of at least 4.5:1; meaning must not be conveyed by color alone.
Alternative text describes the role of the image; for a decorative image the alt is empty.
Accessibility is a design consideration, not a later fix.
Review questions
What does POUR mean, and which principle does keyboard access belong to?
Does the text color #767676 on a white background meet the AA requirement for normal text? Why?
When is an empty alt="" correct?
Give an example of a temporary and a situational barrier!
Learning resources
WCAG 2.2 (W3C) — the text of the guideline and the success criteria; advanced reading.
Accessibility and inclusive design
Objectives
By the end of the lesson, you can explain why accessibility is not the concern of a narrow group, you know the four principles (POUR) and levels of WCAG, you can calculate the contrast ratio of a text–background color pair, and you know how to write alternative text for an image.
Why do we talk about this in a web course?
A university course-registration page is used by many kinds of people. One student is color-blind, so cannot see the red error message. Another works with a keyboard only for a few weeks because of a hand injury. A third watches the video briefing on a noisy train, so wants captions. A fourth tries to read the page on a slow, old phone in strong sunlight. The problem is not that these people use the system in "abnormal" circumstances, but that the system was built for an imagined user who works with a mouse, has good eyesight, and sits on a fast network.
The original promise of the web was that information is reachable regardless of device and place (1.1). Accessibility makes this promise serious: the content and the functions can be used by as many people as possible, in as many situations as possible. There are business, legal, and ethical reasons for it too, but from a developer's viewpoint the simplest reason is that a service fulfils its task only if its target audience can really use it.
Inclusive design emphasizes that we should not try to fix the system at the end for a narrow group, but already at design time ask: who can be left out of this decision? A real button is focusable and keyboard-activatable by default; fixing a clickable
divafterwards brings along many forgotten details (see 9.2).Barriers: it is not only about disability
That is why it is useful to think along the "spectrum of abilities". Captions are indispensable for a deaf user, but they also help many other people when learning a language or watching a video without sound. A good heading structure is a navigation tool for those working with a screen reader, but it gives everyone more scannable content.
flowchart LR C[Content] --> P[Perceivable] C --> K[Operable] C --> E[Understandable] C --> M[Robust]The WCAG approach: POUR
WCAG (Web Content Accessibility Guidelines) is the web accessibility guideline of the W3C (1.2). According to the W3C's page the current version is WCAG 2.2: it does not supersede 2.1 and 2.0 but is backward compatible, meaning that content conforming to 2.2 also conforms to the earlier ones. WCAG 2.2 declared a single earlier requirement, 4.1.1 Parsing, obsolete. WCAG 3 is still an early draft. The guideline is not a checklist spell but a thinking framework. Its four principles can be remembered by the acronym POUR:
The error message example: "Invalid data" is no help; "The email address is missing the @ sign" is.
Levels
WCAG expresses conformance in the levels A, AA, and AAA. In practice the AA level is a common goal. The point, however, is not the "sticker": a formally conforming page can also be hard to use if we have not tried the real user tasks.
Some requirements of the WCAG 2.2 AA level that are also touched on in this course:
Contrast, color, and readability
The contrast ratio expresses how well the text separates from the background: it is calculated from the ratio of the relative luminance of two colors, between 1:1 (the same color) and 21:1 (black–white). This is not a matter of taste: on a weak display, with tired eyes, or in strong light even a sighted user can lose the information. Calculated by the WCAG formula, on a white background:
#aaaaaa(pale gray)#767676#595959#17365d(dark blue)#ff0000(red)(We calculated the values in Node.js with the WCAG relative luminance formula.) The red example is instructive: the same color is fine for a large heading, but not for body text.
Alternative text: describe the meaning of the image
The
altattribute is not for repeating the file name. Achart-final-v2.pngtells nothing to a screen reader. The alternative text conveys the role the image plays in the given context.alt="Blue backpack, front view"alt="The number of registrations grows steadily from January to June"alt=""alt+ a detailed description in the textWith a missing
alt, assistive technology does not know whether the image is decorative, so it may bring noise into the reading by announcing the image or reading out the file name; an emptyalt, by contrast, is a clear signal: this image carries no information. In the next lesson we will see that the automatic checker notices a missingalt, but cannot judge whether the text of thealtis meaningful.Worked example: a fixed event page in Kurzuspont
On the page of a faculty lecture in Kurzuspont, the time appears next to a tiny calendar icon, the enrolment is a colorful box labeled "Click here!", and the venue is shown on an embedded map. In a more inclusive version the page is structured with real headings; the time is readable as text too; the enrolment is a real, clearly labeled button or link ("Enrol for the lecture of 18 September"); below the map there is a text address and route information; the contrast of the text is at least 4.5:1.
We did not make a separate "page for the blind". We made the same page more understandable for everyone. This is the typical pattern of good accessibility decisions.
How do we start in practice?
Fixing an existing page is best started with the most important user paths: can the information be found, can the main operation be started, can the form be submitted? A simple manual test: go through the page with the Tab key, zoom in the browser, turn off the sound of a video, and see whether the interface remains understandable. Automated checkers are quick, but their findings must be interpreted with human judgment (9.2).
Accessibility should not be a single checking day at the end of a project. When designing a new component, the team can immediately decide on the appropriate HTML element, the focus state, the error messages, and the small-screen behavior; this way fewer later fixes are needed.
Common misconceptions
In brief
altis empty.Review questions
#767676on a white background meet the AA requirement for normal text? Why?alt=""correct?Learning resources