Accessibility is often treated as a specialist task for later. In practice a handful of basic fixes remove most of the barriers on a typical business website, and most of them also make the site better for everyone: clearer to read, easier to use on a phone, and easier for search engines to understand.
The standard most people refer to is the Web Content Accessibility Guidelines (WCAG). Level AA is the target in most laws and procurement rules. You do not need to read it to start. These ten fixes cover the problems that appear most often, and each has a test you can run in a few minutes.
1. Make text easy to read
WCAG asks for a contrast ratio of at least 4.5 to 1 between normal text and its background, and 3 to 1 for large text. Light grey text on white is the most common failure.
Test: paste your text and background colours into any contrast checker, or use the colour picker in your browser's developer tools, which shows the ratio.
2. Use the keyboard, not just the mouse
Some people never use a mouse. Everything that can be clicked must also be reachable and usable with the Tab, Enter, Space and arrow keys, in a sensible order.
Test: put your mouse aside and press Tab through the page. Can you reach every link, button and form field? Can you open the menu and close it again?
3. Show where the focus is
When a keyboard user tabs to a link, there must be a clear visible outline or highlight. Removing it because it looks untidy is one of the most common mistakes.
Test: while tabbing, can you always tell which element is active? Design a focus style that fits your look instead of removing it.
4. Label every form field
A field needs a visible label tied to it in the code, not just placeholder text that disappears when you start typing. Group related fields, mark required ones and write error messages that say what to fix.
Test: click a label. The cursor should jump into its field. If it does not, the label is not connected.
5. Give meaningful images a text alternative
An image that carries information, such as a chart, a product photo or a button made of an icon, needs short alternative text describing what it shows or does. Purely decorative images should have empty alternative text so screen readers skip them.
Test: turn images off, or read the alternative text of each one. Does the page still make sense?
6. Build a real heading structure
Use one main heading per page and nest the others in order: sections, then subsections. Headings are how people using screen readers skim a page, and how search engines understand it. Do not choose a heading level because of how big it looks.
Test: list the headings. Do they read like an outline of the page?
7. Write link text that makes sense alone
"Click here" and "read more" mean nothing out of context, and screen reader users often browse a list of links. Make the link text describe the destination: "Read the pricing guide".
Test: read only the links on the page. Would you know where each goes?
8. Make targets big enough to tap
WCAG 2.2 sets a minimum target size of 24 by 24 pixels with spacing, and common design guidance recommends about 44 pixels for touch. Tiny icons and links packed close together are hard for anyone with limited dexterity, or anyone holding a phone with one hand.
Test: on a phone, can you tap every button on the first try without hitting its neighbour?
9. Let people zoom and resize
Never disable pinch zoom. The page should still work when text is enlarged, and at a width of 320 pixels it should reflow into a single column with no sideways scrolling.
Test: zoom the page to 200 and then 400 percent in your browser. Does anything overlap, get cut off or need horizontal scrolling?
10. Do not rely on colour alone
A red border on an invalid field, or a green and red chart, tells nothing to someone who cannot tell the colours apart. Add text, an icon or a pattern as well.
Test: look at the page in greyscale. Is every meaning still clear?
Beyond the ten
Once these are in place, add captions or transcripts for video and audio, avoid content that flashes, make sure moving content can be paused, and give every page a descriptive title. Run an automated checker such as axe or Lighthouse for the things it can find, and remember that automated tools catch only part of the issues, so a manual pass with a keyboard matters.
Make it part of the build
Fixing accessibility after launch costs far more than building it in. Choose colours that pass from the start, use real buttons and links instead of clickable boxes, and test with a keyboard before every release.