A business owner can spot important website accessibility problems by trying the main customer journey with a keyboard, enlarged content and realistic form errors. Record what you did, what happened and what prevented progress. These checks support a better sign-off conversation; they are not a complete accessibility audit or certification.
W3C's Easy Checks resource explicitly warns that a page can pass basic checks and still contain significant barriers. Use the exercise below to find issues and decide where specialist assessment is needed.
Choose one important task
For a fictional equipment-hire business, the task might be: find the relevant equipment category, understand the enquiry requirements and request availability. Select the actual pages and controls involved, including navigation and any confirmation message.
Record your browser, device and starting page. Use approved test data. If the site is live, agree how test enquiries will be identified so the operations team does not mistake them for customer requests.
Run a guided manual test
Test 1: follow the journey without a mouse
Use the keyboard to move through navigation, links, form fields and buttons. Observe whether you can identify the current position, open the intended controls and move away from them. Try the main menu and any dialog that appears.
An actionable finding is: “The service menu opens, but I cannot reach its links using the keyboard.” It describes a specific barrier. W3C's keyboard guidance explains the underlying expectation that functionality can be operated through a keyboard interface, subject to its stated exceptions.
Test 2: enlarge content and check the task again
Increase browser zoom and revisit the chosen journey. Look for text that overlaps, controls that disappear and content that becomes difficult to reach. On a narrow screen, check whether essential content remains readable without repeatedly panning across ordinary paragraphs.
Record the actual zoom setting and viewport used. These observations are a practical starting point; the developer should assess relevant requirements, including W3C's reflow guidance, rather than treating one device test as comprehensive proof.
Test 3: provoke a correctable form error
Leave a required field blank and submit the form. Then try a deliberately incorrect format where appropriate. Can you identify the field that needs attention and understand the correction? Does the page preserve other information you already entered?
A useful issue description is: “Submitting without an email shows a red border, but no explanation identifies what is missing.” W3C's error-identification guidance explains why detected input errors need to be identified and described in text.
Test 4: review meaning beyond appearance
Ask the team to show the page's heading structure and image alternatives. Read headings in sequence: do they describe the content beneath them? Check whether essential information appears only inside an image, unexplained icon or colour distinction.
For meaningful photographs, confirm that their purpose is conveyed appropriately. Decorative images should not produce distracting descriptions. The correct treatment depends on the image's role in that specific page.
Test 5: flag contrast concerns for measurement
Look at small text, muted labels and text placed over photography. Note anything difficult to distinguish from its background. Visual judgment can identify concerns, but ask the reviewer to measure relevant combinations against W3C's contrast guidance. A brand colour preference does not establish whether a combination is usable.
Write an issue log the team can act on
Use one record per problem with the page, test setup, steps, observed result, expected behaviour and effect on the task. Add a screenshot where helpful, without including personal or confidential information.
For example: “On the enquiry page at enlarged zoom, the submit button sits behind the fixed contact bar. I cannot complete the request. Expected: the button remains reachable.” The responsible developer can reproduce that report and explain the proposed fix.
Separate “task blocked,” “task difficult” and “question for specialist review.” Assign an owner and retest the original steps after a correction. Keep unresolved findings visible in the sign-off record.
Separate the symptom from the diagnosis
A business reviewer does not need to identify the exact code defect to report a useful accessibility problem. If a menu cannot be reached during the agreed keyboard test, describe the controls used and the point at which progress stopped. Let the technical reviewer investigate the cause.
Compare these fictional reports. “The website is inaccessible” gives the team no reproducible steps. “From the equipment page, I tabbed through the header and could not reach the category menu; the visible pointer control opened it” gives them a concrete starting point. Add the browser and device, but avoid declaring a standards failure unless the relevant assessment supports it.
Try the same task with realistic content
Short sample headings and empty forms can hide layout problems. Repeat the test with the longest approved service name, a realistic enquiry and any translated content included in scope. Check error states as well as the initial page.
For the fictional hire company, the review could include a long equipment category name and an availability message. At enlarged zoom, does the full name remain understandable? After a validation error, can the visitor find the relevant field and continue? These are observations about the task, not a complete catalogue of accessibility requirements.
Review repeated components across more than one context. A fixed contact bar may behave differently on a long service page and a short enquiry page. Record whether the issue affects a particular page or a shared component so the developer can check the wider impact of a correction.
Make design constraints visible
If a preferred colour combination is difficult to read, ask the designer for an alternative that can be assessed properly. If the logo or identity rules are still being developed, raise usable text and control treatments in the branding discussion. Brand consistency and practical readability should be considered together.
Similarly, agree accessibility-related review expectations before choosing complex interactions in the website development scope. A business owner can ask how navigation, forms and important tasks will be assessed without prescribing a technical implementation. Clarify which specialist reviews are included and which require separate agreement.
Retest with the original steps
When a developer reports a fix, repeat the recorded action in the same setup, then inspect nearby behaviour. If the submit button was hidden by a fixed bar, confirm it is reachable and check that the change did not obscure another control. Record the new observation rather than simply changing the status to “done.”
A useful resolution note says: “Original steps repeated; button reachable at the recorded zoom; enquiry test completed.” If the issue persists only under another setup, create a clear follow-on record. Keep the scope of the evidence visible instead of concluding that one corrected page proves the whole website works for everyone.
Use the findings to guide sign-off
Bring unresolved barriers, incomplete tests and specialist questions into the final review. Ask who owns each next step. Avoid accepting an unexplained score as the entire answer, or dismissing a task-blocking problem because the default desktop view looks attractive. The immediate deliverable is an honest, reproducible issue record and a clear decision about further review.
Frequently asked questions
Does passing these checks mean the website is accessible?
No. They cover a limited set of observations. Comprehensive evaluation requires broader testing and appropriate expertise.
Can an automated checker do this instead?
Automated tools can support review, but do not use one report as a substitute for testing real tasks and reviewing issues that require human judgment.
Should I test only the homepage?
No. Include the pages and interactions needed for important tasks, especially forms, menus and any different page templates.
Who should decide whether an issue is resolved?
The delivery team should demonstrate the correction against the agreed test. Use a qualified accessibility reviewer where specialist judgment is required.
Plan your next project with Tralionex
Discuss accessibility review expectations when planning website development with Tralionex. Agree what will be tested, who will review findings and how unresolved issues will be documented before sign-off.
No comments:
Post a Comment