Picture an application form: the spacing is balanced, the colours match the brand and the submit button stands out. Yet when you let go of the mouse you cannot reach that button, and when you make a mistake you cannot tell which field needs fixing. A screen that looks finished may still not let the user finish their task.
Accessible web design aims to close that gap. It is not about adding a separate settings panel; it is about making the core interactions work across different ways of using them. Keyboard, contrast and forms are concrete starting points — though they do not make up the whole scope of accessibility.
This guide proposes a development and testing approach using a hypothetical service application flow. The WCAG 2.2 criteria selected provide a technical basis; completing these checks alone does not amount to a declaration of full conformance.
Start by completing a real task with the keyboard
Move from the home page to the application form, fill in the fields, use the help dialog that opens, and submit. As you move forward with Tab, try going back with Shift+Tab as well. The goal is not merely to reach every element, but to complete the task in a meaningful order.
WCAG's keyboard criterion requires functionality to be operable through a keyboard interface, apart from defined exceptions such as input that depends on the path of movement. Binding a submit button to a mouse click alone does not meet that basic expectation. W3C: Keyboard.
In development, start with native HTML elements: links for navigation, buttons for actions. Building a clickable box and imitating keyboard behaviour afterwards creates new responsibilities that are easy to forget. If visual order and document order have diverged, fix the layout; managing a long sequence with positive tabindex values tends to be fragile.
Focus has to show where it is
When the user presses Tab, they must be able to tell which element is active. If you remove the default focus outline, replace it with an indicator that is clearly visible. A colour change that appears only on mouse hover is not adequate keyboard feedback. W3C: Focus Visible.
Test with a sticky header and a cookie notice in place too. WCAG 2.2's criterion 2.4.11 at AA level requires that the focused component is not entirely hidden by author-created content; that is not the same threshold as never being partially covered. Aiming in your design to keep the whole component visible produces a more usable result. W3C: Focus Not Obscured.
A dialog must not lose focus
When a help dialog opens during the application, move focus to a meaningful starting point. While a true modal is open, keyboard focus must not escape to the form behind it, and on closing it should usually return to the button that opened it. Escape behaviour and a visible close control are part of the flow too. W3C: Modal Dialog Pattern.
Judge contrast by measurement, not by colour names
“The grey got a bit darker” is not an acceptance criterion. For WCAG AA, normal text requires a contrast ratio of at least 4.5:1 and large text at least 3:1. The large-text threshold is 18 point at normal weight or 14 point bold; not every heading automatically falls into that class. The criterion includes defined exceptions such as logos and inactive components. W3C: Contrast Minimum.
Do not run the check only on colour swatches in the design file. Over a translucent area, a photograph or a gradient, the real background can differ. Examine the form's normal, focused and error states separately. Having a dark theme does not in itself deliver readability either.
For the visual information needed to identify user interface components, and for meaningful graphics, a 3:1 ratio against adjacent colours is assessed separately. That does not mean every decorative line on the page carries the same requirement. W3C: Non-text Contrast.
The form has to state information and errors clearly
Give the email field on the application form a visible label, and associate that label with the field programmatically. A placeholder can offer an example; because it disappears once the user starts typing, it should not take the place of a persistent label. If format or requirement information is needed, it must be understandable before filling in. W3C: Forms Tutorial.
Rather than marking an invalid field with a red border alone, describe the problem in words. Instead of “Invalid input”, use wording that helps with the correction, such as “The email address must contain an @ sign and a domain name”. Do not clear all the fields the user filled in correctly just to let them resubmit.
The relationship between the error message and the field has to reach assistive technologies as well. Where appropriate, aria-describedby can connect the description and aria-invalid can express the field's error state. If you use an error summary, links that take the user to the relevant field are helpful. After adding these attributes, test whether they are actually announced. W3C: Form Notifications.
Put the success screen in scope too
When the form saves, the user must be able to understand what happened. Do not settle for the button briefly turning green. Show a persistent result explaining that the application was received, along with brief information about what happens next.
If a reference number is generated, for example, you can present it as copyable text. When saving the application fails, do not show the same success screen. Letting accessibility testing drift away from business rules can leave a flow that is technically navigable but misleading.
Turn problems into reproducible tasks
Instead of “the form is not accessible”, write the environment, the steps and the expected result. An example record: “On the application page, opening the help dialog moves Tab focus to the submit button behind it; focus should stay inside the modal.” A task written that way can be developed and retested with the same steps.
In testing, note the browser, the assistive technology used and their versions. Complete the core task with zoom enabled, on a narrow screen and with long error messages as well. Automated scanning, keyboard review and screen reader testing belong alongside each other, not in place of one another.
When prioritising, deal first with problems that block the application entirely. Then improve misleading labels, invisible focus and readability. When a single component is fixed, check the other instances of that component on other pages; the problem may not belong only to the screen where you saw it.
Implementation checklist
- Complete the main user task without using a mouse.
- Verify that the forward and backward keyboard order is meaningful.
- Test the focus indicator against sticky menus and notifications.
- Check modal opening, closing and focus return.
- Measure text and component contrast against real backgrounds.
- Add persistent labels and any required descriptions to fields.
- Associate error messages with their fields; preserve entered data.
- Try success, error and pending states separately.
- Retest fixes through the same user flow.
If you would like WebWizz to review an interface, share with us not just the screenshot but the task the user has to complete. We can define the design and development scope from that real flow.
Frequently asked questions
Is a high score on an automated test enough?
No. The presence of a label can be measured, but whether it makes sense in its business context is assessed separately. Do not skip manual checks such as completing a task with the keyboard and testing with assistive technology.
Can 3:1 contrast be used for all text?
No. That threshold applies to large text; for normal text the AA threshold is 4.5:1. Check whether the text really falls under the definition of large text.
Does adding ARIA fix broken keyboard behaviour?
Not on its own. Role or state information does not automatically give a clickable box all the behaviours of a button. Choose the appropriate native element and test the interaction separately.
Once this list is done, can we declare WCAG AA conformance?
No. Full conformance covers the relevant A and AA criteria, complete pages and complete processes — not only these three areas. Document clearly what was reviewed and what limitations were found. W3C: Conformance Requirements.