How to Audit a Learning Course Against WCAG Accessibility Standards

The video opens, the quiz accepts answers, and the certificate arrives after completion. For the author, the course works. Yet a student using only a keyboard cannot close a pop-up. Another cannot understand a diagram without an explanation, while a screen reader user hears an unclear link instead of the assignment's name. These problems remain invisible if you test the product only in your usual way on one device.

An accessibility audit helps identify these barriers and turn them into verifiable tasks. An online school needs to assess the entire route to a learning action as well as the lesson page: registration, payment, sign-in, viewing, practice, receiving feedback, and completion. One inaccessible link in the chain can block the entire process regardless of lecture quality.

Starting points include WCAG 2.2 and the WCAG-EM 2.0 methodology. These are different documents: the criteria describe requirements, while the methodology helps organize evaluation. The process below is a practical adaptation for a learning product; it does not replace a professional assessment of all applicable requirements when a formal conformance claim is needed.

Define the Scope of Evaluation

Record exactly what the audit covers: one course, the learning portal, the catalog, or the whole product including external payment. List the domains, documents, video players, embedded exercises, and services students encounter. Without this description, a team may assess an attractive lesson while missing the fact that an inaccessible sign-in form prevents students from reaching it independently.

Also record the program version and date. Materials and interfaces change, so conclusions must relate to a specific state of the product. Do not include unfinished parts of the course in the result by default. You can evaluate a template or prototype, but this does not establish the accessibility of future actual materials containing tables, quizzes, and different media.

Identify user roles separately. Students, teachers, and administrators perform different actions. If the task concerns the learning experience, start with the student journey while considering who creates and reviews materials. An inaccessible editor can be a barrier for teachers even when their published lessons appear correct.

Agree on the Goal and Criteria

Record the WCAG version, target level, and purpose of evaluation. Self-assessment before launch, finding critical barriers, and formal conformance evaluation require different depths of work. Do not replace the goal with an arbitrary percentage from an automated scanner. Such a score does not explain which criteria were checked or whether someone can complete the required action.

Determine who has the expertise to draw conclusions. Course authors can clarify instructions or prepare text for an image. Developers own technical component defects. Complex checks require accessibility specialists and appropriate assistive technologies. Do not assign all responsibility to one editor merely because they touched the page last.

Agree on the report format before starting. Practical remediation requires the location, role, reproduction steps, actual result, relevant criterion, and recommendation. If the client also expects a conformance claim, separately agree on the evidence and scope required. Do not promise a formal result unsupported by the selected evaluation scope.

Map the Learning Processes

Create several complete scenarios rather than merely a list of URLs. A new student registers, finds a purchased course, completes a lesson, and submits work. A participant encountering a sign-in error restores access. Someone returns to feedback and submits revisions. Define successful completion for each scenario so evaluation does not stop when the first page opens.

Include error states: an incorrect password, a missing field, an unsupported file, or an expired quiz timer. These are often where guidance disappears, focus is lost, or assistive technology fails to announce a message. An audit limited to the ideal path overlooks situations where students most need clear help.

Remember transitions to external services. If another service provides payment or an interactive exercise, its barriers still affect your learning process. Identify the dependency's owner and possible alternative routes. A third-party provider explains the allocation of fixes but does not make a blocked action less important to the student.

Build a Justified Sample

For a large course, check every unique page and component type: a video lesson, long text, table, submission form, quiz, feedback, and completion page. Include materials from different authors and less common formats that may still be critical. The sample should reflect product diversity rather than contain only the most carefully presented examples.

Keep the selection rationale. Why were these lessons chosen? Which templates repeat? Which elements are unique? If you find a systemic defect, check other uses of the component. One inaccessible button in a shared template may affect dozens of pages, whereas an issue in a single image needs a local edit.

Do not draw conclusions about an entire catalog from casually viewing a few pages. Sampling is part of the methodology and has limits. For complete processes, check every required step of the selected scenario. If a part cannot be tested, record its status rather than treating it as passed because no defects were found.

Combine Automated and Manual Checks

A scanner can quickly find some technical problems but cannot fully assess the quality of a learning explanation or the appropriateness of alternative text. Use it to identify suspicious areas and retest, rather than as a final judge. W3C WAI describes different evaluation approaches that complement one another.

Keep reproducible evidence. For manual checks, record the browser, assistive technology, and action sequence. Do not call every unusual spoken output a violation without checking semantics and the applicable criterion. Equally, do not dismiss a problem merely because your favorite tool missed it. Complex cases require a specialist's targeted assessment.

Involving people with different needs provides valuable information about real experiences. However, a small user test alone does not verify every WCAG criterion. Separate usability observations, identified barriers, and formal conclusions. This lets you use each method honestly according to what it actually demonstrates.

Navigate the Course with a Keyboard

Try completing a scenario without a mouse. Is focus visible? Is the navigation order understandable? Can you open and close menus, control video, choose an answer, and submit work? Check both reaching an element and leaving it to continue the journey.

Do not impose a universal rule that every interactive element activates with the same key. Expected interaction depends on the component. Prefer semantically correct standard elements and test behavior appropriate to their roles. Custom interactions may require much more careful testing, especially nonstandard dragging or dialog boxes.

Describe an issue as a specific scenario failure. For example, after a dialog containing the task instructions opens, focus remains behind it and the student cannot find the close button. This record helps a developer reproduce the situation. A general note to improve interface accessibility provides neither a completion criterion nor a way to verify the fix.

Check Text Structure and Images

Headings should represent structure rather than merely differ in font size. Links should explain their purpose in context. Lists and tables need appropriate structure when they perform those functions. For assistive technology users, these relationships replace some visual cues the author perceives automatically.

Alternative text depends on an image's role. A decorative element and a diagram containing key learning information need different treatments. Do not try to squeeze an explanation of a complex chart into a short list of colors. You may need a separate nearby description, data in an accessible format, or another presentation of the content. Check whether people can complete the task with the information provided.

Enlarge text and change zoom within the selected checks. Look for overlapping buttons, disappearing labels, and loss of content. For visual criteria, use applicable requirements and tools rather than your own sense of sufficient contrast. Looking good on the author's screen does not test all user conditions.

Test Forms Together with Their Error States

Every field should have a clear purpose, with necessary instructions available before entry. Check required fields, answer formats, and messages after failed attempts. If an error is indicated only by color, some students may not understand what happened. Explanations should help correct the action as well as state that it is wrong.

For assignment uploads, check accepted formats, submission confirmation, and the ability to find returned feedback. If students are unsure whether a file was accepted, they may repeat the action or contact support. Accessibility overlaps with process clarity here, but every issue should still be connected to a specific observation and relevant evaluation criterion.

Give complex quiz checks their own scenario. Timer accessibility, answer groups, result messages, and retry behavior need targeted analysis. Do not consider a quiz accessible merely because its first question has a correct label. The complete journey includes completion, errors, and returning to learning after the result.

Include Media and Documents in the Asset Inventory

Video may need captions, another text representation, or descriptions of visual information depending on the content and applicable criteria. Do not treat an automatic transcript as a universal solution for every need. Check whether the selected format conveys meaningful sounds, speech, and information available only on screen.

PDFs and presentations need separate checks of structure, reading order, and content accessibility. An accessible page containing a link does not make the attached document accessible. Record its version and owner. If it cannot be fixed quickly, assess an equivalent accessible alternative without losing the learning task or hiding the limits of the current solution.

When using an external video player or interactive exercise, test your actual configuration. A provider's accessibility claims do not mean the author has correctly prepared captions, names, and settings. Accessibility depends on both the tool and content, so the report should distinguish these sources of problems and the people responsible for fixes.

Turn Findings into Manageable Tasks

For each problem, state its impact on the learning action. A blocked sign-in or assignment submission requires a different priority from a less critical reading difficulty. Prioritization helps plan work but does not remove conformance requirements. Do not call a course fully accessible merely because its most visible barriers have been removed.

Separate systemic and local causes. Fixing a button template can help many lessons, but every meaningful chart still needs a content-specific description. Assign an owner and a verification method. If the issue lies in a third-party service, create a route for reporting it and check an accessible alternative for the current student.

When learning is organized through the WeStudy LMS platform, assess the actual course and verified capabilities of its configuration. Do not infer platform-wide conformance from checking one author-created module. Likewise, do not credit the provider with automatically fixing errors introduced in an uploaded presentation or school-created instruction.

Retest After Remediation

A status of 'fixed' means the required scenario has been retested, rather than simply that a developer changed code. Repeat the same steps and ensure the problem has not returned in another state. For a shared component, check several uses, especially where pages have different settings or content.

Keep a history of findings: what was identified, how it changed, and when it was checked. This helps during the next update when an author accidentally restores an old template. Agreed procedures help with recurring technical checks; W3C ACT provides a separate reference for describing reproducible tests rather than replacing the whole audit.

Include accessibility in routine acceptance of new materials. Editors check structure, authors provide meaningful alternatives, and the technical team checks components and scenarios. Periodic audits can then identify changes and omissions instead of rebuilding basic order each time. This reduces expensive rework after launch and gives participants a more consistent experience.

An Example Issue Record

A hypothetical finding concerns the final assignment. The role is student, the page is the submission form, and the state is an upload error. Selecting an unsupported file produces only a red border without a text explanation. The person does not know what to change and cannot complete a required stage. The record includes exact steps, the expected result, the relevant criterion after specialist assessment, and a link to a test example without personal data.

The recommendation should describe the required experience without imposing an arbitrary technical implementation. For example, the message should help explain the cause and how to correct the action, with its presentation tested using the necessary technologies. After the change, the team repeats the error scenario and then a successful submission. The record is closed with evidence that students can continue, rather than a screenshot of a better-looking red border.

Planning Fixes Before an Upcoming Launch

Suppose launch is a week away and the audit finds many different barriers. First identify which block core processes and which share a cause. One systemic change can sometimes resolve issues across many lessons. Assign owners for local materials and check whether an appropriate alternative is possible. Do not replace prioritization with an arbitrary rule to fix only what is easy first.

If a scenario remains blocked, make an honest decision about launch and support. Personally contacting a tutor may temporarily help someone but is not always equivalent to independent access. Assess the impact on time, privacy, and the learning goal. Unresolved limitations should remain visible to responsible people so a temporary workaround does not become a permanent, invisible dependence on manual help.

Speaking with a Third-Party Provider

Send the provider a specific reproducible case rather than a general question about whether its product is accessible. State the component, role, state, environment, and impact on the action. Ask whether the issue is known, what fix is possible, and when it can be retested. Keep the response with the issue record so someone else can continue without reconstructing all correspondence from scratch.

Do not automatically accept a response that the service supports the standard. The problem may arise from your configuration or require a product change. Test the proposed solution on the same example. If the provider sends a conformance report, clarify its date, scope, and version. The document may provide useful procurement evidence without covering every aspect of the particular course and the school's own materials.

Preparing for a User Session

Give participants a realistic task and verified test data rather than instructions for clicking every button. Ask them to complete the action in their usual way and allow their own settings where compatible with the evaluation goal. Agree on recording, duration, compensation, and handling the information gathered. Participants should not provide all the team's missing expertise for free or be treated as the sole representative of every possible need.

During the session, separate observations from your own explanations. If someone stops, find out what information they sought and what they expected. Avoid immediately prompting an answer if this would conceal a barrier, but do not make them repeatedly attempt an impossible action. Compare findings with technical checks afterward. The team then gains both real-use context and a basis for targeted conformance analysis.

Maintain Accessibility After Editing

A small update can restore a barrier: an author inserts an image instead of text, replaces a descriptive link with 'here,' or adds an exercise that cannot be completed with a keyboard. Define brief acceptance checks appropriate to the change type. Replacing an ordinary paragraph does not require auditing the entire product, but a new interactive component needs its own testing and a check of the learning scenario.

Keep a library of verified examples: table formatting, assignment structure, ways to present complex diagrams, and caption preparation rules. This helps authors work consistently. A template does not guarantee the quality of every new piece of content, however. A meaningful chart still needs explanation, and a new question needs checking in context. Combining team training with specific change acceptance makes accessibility a routine part of course production rather than a one-off campaign before an external assessment.

Write an Honest Conclusion

State the scope, date, environment, sample, checks performed, and unresolved issues in the report. Distinguish identified violations, usability recommendations, and parts not yet evaluated. Do not turn the absence of automated errors into a certificate. If an official statement is required, prepare it according to verified facts and the necessary procedure.

If the WeStudy LMS platform forms part of the learning journey, the report can help allocate requests between the school and provider. For students, however, the outcome of the whole service matters: can they perform the required action? Start with one complete scenario, find barriers, and verify fixes. Then expand coverage while remaining precise about what you have already evaluated.

Before handing over the report, check the document's own accessibility: heading order, clear link names, and text explanations for screenshots. The team should be able to use audit findings through the same means it supports for students. An accessible report also makes later task searches and independent verification of conclusions easier.

Sources

1. W3C — WCAG 2.2.

2. W3C — WCAG Evaluation Methodology 2.0.

3. W3C WAI — Evaluating Web Accessibility.

4. W3C — Accessibility Conformance Testing.

5. W3C WAI — Easy Checks.