By the end of the lesson, you understand that accessibility is not a retroactive favor for special users, but a basic condition of a good digital service. You know the four principles of WCAG (POUR), and you can recognize the basic risks in the areas of color, contrast, keyboard, text, and feedback.
Why is accessibility not "extra"?
Many people think of accessibility as a separate feature that can be added at the end, if there is time. This is wrong for two reasons. First: very many people are affected. Besides a user with a permanent visual impairment, there is someone who does not have a hand free (because they are holding a child), someone whose screen is washed out by sunlight, whose eyes are slow from tiredness, or who reads in a second language. Second: adding accessibility afterwards is much more expensive than building it correctly from the start. Whoever designs accessibly from the beginning fixes less.
Who are we designing for?
Accessibility is ensuring that content is usable with different abilities and assistive technologies. Inclusive design is a broader approach: it does not ask how to make a separate version for someone, but who can be left out of the current decision.
A well-known illustration (from Microsoft's inclusive design materials): the same limitation can be permanent (a missing arm), temporary (a broken arm), and situational (a small child in the arm). If we design well for one situation, it will be good for the other two as well.
The POUR approach of WCAG
WCAG (Web Content Accessibility Guidelines) is an international system of guidelines for web content accessibility, published by the W3C (World Wide Web Consortium). It is the reference basis for most legal and professional expectations. Its four principles are POUR: Perceivable, Operable, Understandable, Robust.
Perceivable: the information can be taken in in some way.
An image needs meaningful alternative text (for the user who cannot see the image and for the screen reader), a video needs captions or a transcript.
A state indicated only with color needs an additional signal.
Text must remain high-contrast and enlargeable.
Operable: every essential function can be used.
We cannot assume a mouse, touch, or fast reaction.
The focus should be visible, the keyboard order logical.
Movement or a time limit should not obstruct the task; the touch target should be large enough.
Understandable: the text, the behavior, and the error message are clear.
"Invalid data" is not enough; "The email address is missing the @ sign" helps to fix it.
Unexpected state changes and inconsistent naming are also understandability problems.
Robust: the interface is built on a standard structure that can be interpreted in various browsers and with assistive technologies. This is why semantic elements (a real button, a real list, a real heading) and correctly used labels matter. ARIA (Accessible Rich Internet Applications) is a supplementary markup system that can communicate the role of complex elements to assistive technology; still, the first choice is the appropriate native element.
Conformance levels
WCAG formulates requirements at three levels (A, AA, AAA). AA is the level that most laws and services set as a target; this course also refers to it. A is the most basic, AAA the strictest, but it cannot be met for all content. The current, widely referenced version is WCAG 2.2.
Contrast, color, and signaling
Contrast ratio is a measure of the difference in brightness between foreground and background. The main expectations of level AA:
Element
Minimum contrast ratio
Normal-sized text
4.5 : 1
Large text (about 24 px, or 19 px bold)
3 : 1
Borders of interface elements, icons, focus indicator
3 : 1
These are not decoration rules. On a poor display, in sunlight, or with tired eyes, weak contrast can cause problems for everyone. You can measure contrast with a tool (there are plugins for Figma, and browser checkers too), but the decision is yours.
Color should be a supplementary signal, not the only one. It is wrong if a form field gets only a red border. It is better if the border is accompanied by a text error message, an icon, and a programmatic connection. On a chart, a label, pattern, or direct label next to the colors can help. For people with color vision deficiency (roughly one in twelve men) the red–green distinction is unreliable.
Keyboard and focus
Focus is the state of the interactive element currently controlled by the keyboard. For a quick manual check, put the mouse aside and walk through the interface with the Tab key. Questions:
Can you always see where you are? (Visible focus indicator.)
Is the order in which you move logical?
Are the menu, the form, and closing reachable?
Do you get trapped in an element?
With a pop-up window, the focus has to move into the window, the background elements must not remain accidentally reachable, and on closing, the focus must return to a sensible place. No other element should cover the focus indicator.
Touch target and text
On mobile there is a separate rule for the size of elements operated by finger: WCAG 2.2 level AA expects touch targets of at least 24 × 24 CSS pixels, but a comfortable size is generally larger (platform guidelines typically recommend 44–48 points). For text, it is important that no content or function is lost even at 200% zoom; this is also a condition of responsive design.
Worked example: the event page of Mai program
On a lecture's page, the time appears only as a calendar icon, the location only on a map, and the registration as a box labeled "Click here!". The accessibility problems:
the time is an icon, without text (perceivability);
the map cannot be used with a screen reader (perceivability);
the "Click here!" box is actually not a button (robustness, operability);
the contrast of the label is low (perceivability).
In a more inclusive version, the date and the address are also there in text; the registration is a real button with a clear label ("Register for the event"); the map is accompanied by textual route information. We did not make a separate page for a group: we made the same task more understandable for everyone.
Common misconceptions
Claim
Clarification
"The automatic checker finds everything."
A tool can signal a missing label or contrast, but cannot judge whether the alternative text or the task flow is meaningful.
"ARIA solves the semantics."
ARIA is a supplementary tool; the first choice is the appropriate native element.
"Accessibility limits creativity."
Rather, it gives a framework in which the visuals remain understandable and operable as well.
"Accessibility is about the visually impaired."
It also affects users with motor impairments, hearing impairments, cognitive differences, and situational limitations.
In brief
A barrier can be permanent, temporary, or situational; inclusive design asks who is left out.
The four principles of WCAG: perceivable, operable, understandable, robust (POUR); the target is level AA.
Text contrast is at least 4.5 : 1, for large text and interface elements 3 : 1.
Color can never be the only signal; always check keyboard and focus use.
Manual checking (Tab, zoom) is indispensable; the automatic tool only helps.
Review questions
What do the four letters of POUR stand for?
Why is it not enough to mark an error with color only?
What would you watch for when walking through with the Tab key?
Which information in your project appears only visually?
What situational limitation can you imagine when using Mai program?
Inclusive design and WCAG
Objectives
By the end of the lesson, you understand that accessibility is not a retroactive favor for special users, but a basic condition of a good digital service. You know the four principles of WCAG (POUR), and you can recognize the basic risks in the areas of color, contrast, keyboard, text, and feedback.
Why is accessibility not "extra"?
Many people think of accessibility as a separate feature that can be added at the end, if there is time. This is wrong for two reasons. First: very many people are affected. Besides a user with a permanent visual impairment, there is someone who does not have a hand free (because they are holding a child), someone whose screen is washed out by sunlight, whose eyes are slow from tiredness, or who reads in a second language. Second: adding accessibility afterwards is much more expensive than building it correctly from the start. Whoever designs accessibly from the beginning fixes less.
Who are we designing for?
Accessibility is ensuring that content is usable with different abilities and assistive technologies. Inclusive design is a broader approach: it does not ask how to make a separate version for someone, but who can be left out of the current decision.
A well-known illustration (from Microsoft's inclusive design materials): the same limitation can be permanent (a missing arm), temporary (a broken arm), and situational (a small child in the arm). If we design well for one situation, it will be good for the other two as well.
The POUR approach of WCAG
WCAG (Web Content Accessibility Guidelines) is an international system of guidelines for web content accessibility, published by the W3C (World Wide Web Consortium). It is the reference basis for most legal and professional expectations. Its four principles are POUR: Perceivable, Operable, Understandable, Robust.
Perceivable: the information can be taken in in some way.
Operable: every essential function can be used.
Understandable: the text, the behavior, and the error message are clear.
Robust: the interface is built on a standard structure that can be interpreted in various browsers and with assistive technologies. This is why semantic elements (a real button, a real list, a real heading) and correctly used labels matter. ARIA (Accessible Rich Internet Applications) is a supplementary markup system that can communicate the role of complex elements to assistive technology; still, the first choice is the appropriate native element.
Conformance levels
WCAG formulates requirements at three levels (A, AA, AAA). AA is the level that most laws and services set as a target; this course also refers to it. A is the most basic, AAA the strictest, but it cannot be met for all content. The current, widely referenced version is WCAG 2.2.
Contrast, color, and signaling
Contrast ratio is a measure of the difference in brightness between foreground and background. The main expectations of level AA:
These are not decoration rules. On a poor display, in sunlight, or with tired eyes, weak contrast can cause problems for everyone. You can measure contrast with a tool (there are plugins for Figma, and browser checkers too), but the decision is yours.
Color should be a supplementary signal, not the only one. It is wrong if a form field gets only a red border. It is better if the border is accompanied by a text error message, an icon, and a programmatic connection. On a chart, a label, pattern, or direct label next to the colors can help. For people with color vision deficiency (roughly one in twelve men) the red–green distinction is unreliable.
Keyboard and focus
Focus is the state of the interactive element currently controlled by the keyboard. For a quick manual check, put the mouse aside and walk through the interface with the Tab key. Questions:
With a pop-up window, the focus has to move into the window, the background elements must not remain accidentally reachable, and on closing, the focus must return to a sensible place. No other element should cover the focus indicator.
Touch target and text
On mobile there is a separate rule for the size of elements operated by finger: WCAG 2.2 level AA expects touch targets of at least 24 × 24 CSS pixels, but a comfortable size is generally larger (platform guidelines typically recommend 44–48 points). For text, it is important that no content or function is lost even at 200% zoom; this is also a condition of responsive design.
Worked example: the event page of Mai program
On a lecture's page, the time appears only as a calendar icon, the location only on a map, and the registration as a box labeled "Click here!". The accessibility problems:
In a more inclusive version, the date and the address are also there in text; the registration is a real button with a clear label ("Register for the event"); the map is accompanied by textual route information. We did not make a separate page for a group: we made the same task more understandable for everyone.
Common misconceptions
In brief
Review questions