Not a courtesy for a minority — a question of quality. Can it be used outdoors in bright sun, one-handed, carrying something? And for public sector work it is a legal requirement.
10 terms10 live demos
Put the mouse away and try it
Fastest review there is. Tab to move, Enter to activate, Esc to close. If you can get all the way through on that alone, most of it passes.
01
Accessibility
접근성 · a11y
When this comes up
"Cover accessibility too" — on public sector projects it is a legal requirement.
Making something usable by anyone, regardless of disability, age, device or circumstance. a11y is shorthand — eleven letters between the a and the y of accessibility.
See it Try clicking
· someone who cannot see → listens with a screen reader
· someone with limited hand movement → operates by keyboard alone
· someone colour-blind → struggles to tell red from green
· anyone outdoors in bright light → sees nothing if contrast is low
Easy to get wrong
Accessibility is not a courtesy to a minority; it is quality for everyone. Can it be used in bright sunlight, carrying something in one hand, on a noisy train? That is all accessibility. And for public sector work it is a legal requirement — fail it and delivery is rejected.
Using it on the job
Accessibility is most expensive when bolted on afterwards. Fixing it once the structure is built is close to rebuilding. Design it in from the start.
Ask for it like this
Please build accessibility in from the start — semantic markup, keyboard operation, 4.5:1 contrast, alt text on images. Adding it later means restructuring, which costs far more.
When a public sector tender requires a web accessibility certification mark.
The international web accessibility guidelines. Three levels — A, AA, AAA — with AA the usual target.
See it Try clicking
AMinimum level
AAThe working standard · most projects sit here
AAAHighest level · applying it throughout is unrealistic
Easy to get wrong
Korea has KWCAG, its own guidelines derived from these, and public bodies require a web accessibility certification mark. Win a project like that and you must build it in from the beginning — retrofitting is close to starting over.
Ask for it like this
I will target WCAG 2.1 level AA. If this is a public sector delivery, the KWCAG criteria and the accessibility certification review need to be in the schedule too — please let me know whether that applies.
Assistive technology that reads screen content aloud. The main way blind people use the web.
See it Try clicking
What is visible on screen
What the screen reader says ✗ "button", with no name ✓ "Search, button"
Easy to get wrong
A screen reader does not "see" the screen — it reads in code order. So a visually tidy arrangement means nothing if the code order is scrambled. Turn on VoiceOver on iPhone or TalkBack on Android and listen to your own site; the problems surface immediately.
Ask for it like this
Please check that the reading order makes sense with a screen reader. Elements repositioned with CSS alone can have a code order that differs from the visual order, which breaks the meaning.
"Add alt text to the images" — except not every image should have it.
Text describing an image in words. Delivered instead of the image when it cannot be seen or when a screen reader is in use.
See it Try clicking
✗
alt="image1.jpg" / alt="photo"
✓ Informative image
alt="Bar chart showing July revenue up 12% on the previous month"
✓ Decorative image
alt="" (left empty so it is skipped)
Easy to get wrong
It does not go on every image. Decorative images should be left empty so screen readers skip them. Put it only on images carrying information, and leave out words like "image" and "photo" — describe the content. It helps SEO too.
Ask for it like this
Add alt text only to images carrying information, and leave decorative images as alt="" so screen readers skip them. Do not include words like "image" or "photo" in the text.
The first thing to check in a front-end build review.
Using the tag that matches the meaning — heading tags for headings, button tags for buttons.
See it Try clicking
✗ A button made from a div
looks identical · cannot be reached by Tab · cannot be activated by Enter · a screen reader will not call it a button
✓ A button tag
keyboard operation, focus and screen-reader recognition all come for free
Easy to get wrong
Build everything from div and it looks identical while accessibility collapses entirely. A button made of a div cannot be pressed with a keyboard and is not recognised as a button by a screen reader. This is the core review item.
Ask for it like this
Please use button tags rather than divs for buttons, and h1–h6 for headings. Divs break keyboard operation and screen-reader recognition.
"Add the aria attributes" — though not using it is often best.
Extra markup telling assistive technology about roles, states and properties — things like aria-label and aria-expanded.
See it Try clicking
aria-label — a name that is not visible but is read out
aria-expanded — expanded or collapsed state
aria-selected — whether it is selected
role — the role of this element
The category buttons and tabs on this site actually use these.
Easy to get wrong
The first rule of ARIA is not to use ARIA. If the correct HTML tag solves it, that is better; reach for ARIA only when there is no alternative. Badly applied ARIA is worse than none at all.
Ask for it like this
Where a native HTML tag solves it, please build it without ARIA. Use aria-label only where there is no accessible name, such as icon buttons, and aria-expanded to convey accordion state.
"Remove this blue outline" — the same request as "remove the accessibility".
The outline showing where you are when navigating by keyboard.
See it Try clicking
Seeing the outline is the correct behaviour. Without it, keyboard users cannot tell where they are.
Easy to get wrong
"Remove this blue outline" is the same as asking to remove accessibility. Do not delete it — restyle it to suit the brand. There is also a way to hide it for mouse clicks only (:focus-visible) — say that word to a developer and they will know.
Ask for it like this
Rather than removing the focus ring, please use :focus-visible. It stays hidden on mouse click and appears only on keyboard Tab navigation. Restyling it in the brand colour is fine.
When visual order and code order diverge, the tab order goes strange. It happens often when a design moves an element but development repositions it with CSS only. Pressing Tab from top to bottom is the whole review.
Ask for it like this
Please make the Tab order match the visible order. Where elements have been repositioned with CSS only, align the code order too. Do not use positive tabindex values.
The fastest way to review accessibility. Put the mouse away.
Making every function usable with the keyboard alone, without a mouse.
See it Try clicking
Tab / Shift+TabNext / previous
Enter / SpaceActivate
EscClose — the most commonly missed one
ArrowsMove within a list or tab set
Easy to get wrong
The review method is very simple — put the mouse away and use it. Tab (move), Enter/Space (activate), Esc (close) and arrows (select) should get you all the way through. Whether a modal closes on Esc is the most commonly missed item.
Ask for it like this
Please make every function usable by keyboard alone. In particular, modals, drawers and dropdowns must close on Esc, and focus must return to the button that opened them.
"Green for in stock, red for sold out" — that alone is not enough.
The principle of never carrying information by colour alone.
See it Try clicking
✗ Colour only
● In stock● Sold out
✓ Colour + icon + words
✓ In stock✕ Sold out
Easy to get wrong
Around 5–6% of Korean men have a colour vision deficiency. Mark success and failure with red and green alone and both look like the same grey to them. Pair it with an icon, words or a shape. Distinguishing chart lines by colour alone has the same problem.
Ask for it like this
Please do not distinguish states by colour alone — add an icon and words, such as "✓ In stock" / "✕ Sold out". People with colour vision deficiencies struggle to tell red from green.