Design and UX
Accessibility in design
Accessibility is design for the full range of people who will actually use a product, including those who move by keyboard, listen through a screen reader, magnify the screen or process information differently. It rests on a published standard, WCAG, which turns good intentions into testable criteria. For designers it is not a final audit but a run of decisions made from the first wireframe onward, when they are cheapest to get right.
Why this topic exists: WCAG's four principles and conformance levels, assistive technology and inclusive design: NN/g's Accessibility topic, SFIA Accessibility and inclusion, W3C WAI.
Disability is not a rare edge case. It covers permanent conditions, temporary ones such as a broken wrist, and situational ones such as glare on a phone in bright sun. Designing for that range tends to improve a product for everybody, which is why SFIA files accessibility and inclusion under user-centred design instead of under compliance, and why Nielsen Norman Group treats it as a core area rather than a specialism. Assistive technology is the umbrella for the tools people bring with them: screen readers that speak the page or render it in braille, magnifiers, voice control, switch devices and plain keyboard navigation. A design that assumes a mouse and perfect eyesight quietly shuts those users out.
WCAG in four principles
The Web Content Accessibility Guidelines come from the W3C's Web Accessibility Initiative. Versions 2.0, 2.1 and 2.2 are stable recommendations, 2.2 dating from October 2023, and each later version adds criteria without altering earlier ones, so meeting 2.2 also meets its predecessors. Version 3 exists only as a draft. Every guideline sits under one of four principles, and every testable success criterion carries a level.
| Principle | What it asks | A design decision it touches |
|---|---|---|
| Perceivable | Information reaches people through a sense they can use | Text alternatives, captions, colour contrast, never colour alone |
| Operable | Every function works with the input a person has | Keyboard access, visible focus, target size, enough time |
| Understandable | Content and behaviour are clear and predictable | Plain labels, consistent navigation, useful error messages |
| Robust | Content keeps working with assistive technology, present and future | Semantic structure a developer can express in proper markup |
Levels, and what the designer owns
Level A removes the most basic barriers, AA adds the requirements most teams treat as their working target, and AAA is the strictest set. Many failures at any level are settled in the design file long before code exists:
- Contrast between text and background, and between controls and their surroundings.
- Focus order and focus styles, so a keyboard user can see where they are and moves in a sensible sequence.
- Target size and spacing for touch and for people with limited dexterity.
- Colour as the only signal, such as a red border on an invalid field with no text saying what is wrong.
- Headings and labels that describe the content, which screen-reader users rely on to scan a page.
The beginner's mistake is treating accessibility as a checklist run after launch, or as something an overlay script can patch. Automated checkers catch only part of the problem, and the rest needs a person working through the product by keyboard and with a screen reader. Build the requirements into components so they are solved once, include disabled participants in research, and bring developers in early, because accessible markup is their half of the job. Captions and transcripts for video and audio belong in the brief from the start, not in a later sprint. Google's UX Design certificate introduces accessibility in its opening course, a sensible place for the habit to begin.
Next to this topic
- UX researchInterviews, usability tests, surveys, analytics and when to use which: NN/g's Research Methods and User Testing topics; SFIA User research; the fourth course of Google's UX programme.
- UX and interaction designInformation architecture, flows, patterns and the behaviour of interfaces: NN/g's Interaction Design and Information Architecture topics, IxDF's UX and HCI literature, SFIA User experience design.
- UI and visual designLayout, typography, colour, hierarchy and the craft of the screen: NN/g's Visual Design topic, IxDF's UI design, colour theory and Gestalt literature.
- Design systemsTokens, components, documentation and governance so that many hands ship one product: the site's design-system concept, IxDF's brand-guidelines literature, and the meeting point with front-end code.
- Prototyping and design toolsFigma, Sketch, Adobe XD and the prototyping loop from paper to clickable: NN/g's Prototyping topic; Udemy's Design Tools shelf; the third and fifth courses of Google's UX programme.
- Graphic design and illustrationComposition, type, image and print, and the Adobe and Affinity toolchain: SFIA Graphic design; IxDF's graphic design literature; Udemy's largest design shelf after 3D.
- 3D, animation and motion designModelling, rigging, rendering and motion in Blender, Maya, 3ds Max, ZBrush, After Effects and Cinema 4D: SFIA Animation development; Udemy's largest design shelf.
- Web designLayout for the browser, responsive design, WordPress themes and the hand-off to code: Udemy's Web Design shelf; the programming field owns the build.
- Design assets and licensingTemplates, stock media and fonts, and the licences that decide what you may do with them: the site's design-assets concepts and the /digital-assets/ partner picks.
- Design thinking and service designProblem framing, ideation and the end-to-end service: IxDF's design-thinking and service-design literature; NN/g's Design Process and Customer Journeys topics; SFIA Customer experience.
Concepts to know
Glossary entries with the reason each one matters here.
- Design system
Accessible components make accessible products cheaper.
Certifications that test it
Vendor exams and free certificates; facts, cost and the preparation path are on each page, and the certifications hub has them all.
Frequently asked
- Which WCAG version should a new project follow?
- WCAG 2.2, the most recent stable recommendation. Because the 2.x versions are backward compatible, content that meets 2.2 also meets 2.1 and 2.0. Version 3 is still a draft and not yet something to conform to.
- Is accessibility the designer's job or the developer's?
- Both. Designers decide contrast, focus visibility, target sizes, labels, reading order and error messages. Developers turn those decisions into semantic markup, keyboard behaviour and the attributes assistive technology reads. Most failures happen at the hand-off, when a design never specified a state that a keyboard or screen-reader user will meet.
- Can an accessibility overlay make a site compliant?
- No. An overlay sits on top of a page and cannot repair missing structure, unlabelled controls or inaccessible flows, and it can interfere with the assistive technology people already use. Fixing the underlying design and code is the only dependable route.
Courses in the directory
7 courses are filed here; the top 6 by our ranking, details and the provider link on each course page.
Web Accessibility
Udacity
Last reviewed 26 September 2026 · Getting Digital