Accessibility is usually discussed as a value. It is more useful to treat it as a set of tests that a site passes or fails. The standard most organisations work to is WCAG, the Web Content Accessibility Guidelines, and its current version, 2.2, is specific enough to check against.
Start with the keyboard
Put the mouse away and try to use the site with the Tab, Enter, Space and arrow keys. Can you reach every link and button? Can you see where you are on the page? Can you open the menu, close a pop-up and submit a form?
This test takes ten minutes and finds a surprising share of problems: custom dropdowns that cannot be opened, dialogs that trap focus behind them, a focus outline removed because someone thought it looked untidy.
Listen to the page
Screen readers, VoiceOver on Apple devices, TalkBack on Android and NVDA on Windows, read the page aloud in the order of its code. Hearing a site this way quickly shows images described as "image", buttons announced as "button" with no label, and headings chosen for their size rather than their structure.
It also shows whether dynamic changes are announced. A form that shows an error in red text but says nothing to a screen reader leaves its user guessing.
Zoom, resize and change the settings
Many people with low vision do not use a screen reader. They zoom the browser to 200 per cent or more, increase the system font size, or turn on high contrast. A layout that overlaps, truncates text or hides buttons at those settings fails them.
The same goes for motion. Users who have asked their device to reduce motion should not be greeted by parallax and autoplaying video.
Measure contrast, do not eyeball it
Light grey text on white looks elegant on a calibrated monitor and vanishes on a phone outdoors. WCAG sets minimum contrast ratios, 4.5 to 1 for normal text, and they can be measured exactly. We check brand colours against them during design, before a palette is approved, because fixing contrast after launch usually means arguing with the brand guidelines.
Automated tools find some of it
Tools such as axe and Lighthouse catch missing labels, empty links and poor contrast in seconds, and they belong in every build. But they detect only part of the problems a person would find. A page can score perfectly and still be impossible to use with a keyboard. The tools are a floor, not a finish line.
Test the whole journey
A single accessible page is not much use if the checkout that follows it is not. Accessibility testing follows the same journeys as functional testing, from landing to confirmation, including the emails and PDFs that arrive afterwards.
