Accessibility operating handbook

Proposed charter wording for adoption review

For the services and content included in its approved scope, BuildLACCD will incorporate accessibility into planning, procurement, content creation, development, review and maintenance. The proposed technical target is WCAG 2.2 Level AA. Assigned owners will maintain accessible source materials, evaluate representative user tasks, record and resolve barriers, provide an approved assistance route and review results regularly.

The Program owner maintains an inventory and annual plan, assigns review and training responsibilities, retains decisions and test evidence, and reports unresolved barriers and resource needs to the approving authority. Any temporary alternative-access arrangement will identify the affected task, responsible owner, validation, remediation plan and review date.

This is draft policy wording for an authorized decision. The adoption record must identify the exact approved version, covered scope, owners, resources, effective date and review date. Until that decision is recorded, this text remains proposed.

Confirm scope, authority and resources

Before adoption, the approving authority should confirm which domains, services, documents, embedded tools and workflows the charter covers, and whether the proposed WCAG 2.2 Level AA target applies to each. Assign an accountable owner and backup; define release and urgent-issue authority; identify resources, training responsibility, records location and retention rules; name the reporting audience; and set the review date.

Route legal interpretations and formal exception decisions to the District’s designated policy and legal personnel. Record the approval and effective date, then start the recurring work in the companion procedures.

Assign a role to each part of the work

Assign a person and backup to each role after District review. One person may hold multiple roles; a high-impact form or shared component should receive an independent review. The Content editor confirms the accuracy and meaning of image descriptions and document content; the Website team implements those approved requirements.

Record adoption and keep decisions current

Store the approved charter with its review record. Use this field set so later staff can tell which version applied and what was actually decided:

• Record ID; document title and version; decision date; effective date; approving authority and approval evidence.
• Covered sites, services, content types and known exclusions, with an owner for each exclusion.
• WCAG version and level; named accountable owner and backup; delegated release and escalation authority.
• Approved staff time, tools, specialist support and training resources, or items still awaiting allocation.
• Monitoring cadence, reporting audience, record location, retention reference and next review date.
• Open decisions, interim owner, due date and evidence needed to close each decision.

At governance meetings, review new or retired services, unresolved high-impact issues, resource needs, upcoming releases and overdue actions. Record decisions, dissent or deferred questions, owners and next dates. Revisit the charter after a major redesign, a new supplier or a change in scope. See roles and responsibilities for the day-to-day handoff and WCAG 2.2 basics for the difference between the standard and proposed local procedures.

Build the plan from current evidence

Prepare the annual plan from the covered inventory, current issue register, prior review results, user feedback, planned releases, training needs and available staff time. Recheck prior findings against current evidence before marking them open, repaired or distributed to reviewers.

For each activity, define the user or process need, deliverable, accountable owner, contributors, resources, target date, acceptance evidence, dependencies and status. Include recurring monitoring, known-barrier remediation, content workflows, supplier reviews and staff training. Prioritize blocked or time-sensitive tasks, shared components with broad impact, repeat findings and high-use public services. Record why lower-impact work is scheduled later.

Ask leadership to confirm feasibility, allocate time and resolve resource decisions. Dates and assignments become commitments after the authorized owner approves them.

Record plan fields

Illustrative example: “Review the registration flow after the form component update; owner: assigned site owner; target: confirm after release planning; acceptance: keyboard and screen-reader task results, deployed version, unresolved findings and reviewer decision attached.” This example does not describe a completed District activity.

Review progress and report evidence

Use a weekly quick review during active releases to check immediate blockers and deadlines. Hold a monthly thorough review of plan status, new and recurring issues, overdue work and evidence completeness. At quarter end, summarize completed tasks, test scope, barriers still affecting users, changed priorities and decisions needed. At year end, review the full cycle with the approving owner, revise the next plan and retain the evidence package.

The annual evidence package identifies its audience, preparer, review date, covered scope, evaluation method, tools and versions, sampled pages or tasks, results, issue status, training delivered, known limitations and source records. Include raw scan outputs and manual test records where relevant; state exclusions and reasons. Pair each score, count or percentage with its sample, method and denominator, and treat it as a summary rather than conformance evidence by itself.

Distribute the reviewed report through an approved channel and record who received it, when, what decisions followed and which items remain open. WCAG-EM provides a useful structure for defining scope, exploring assets, selecting samples, evaluating them and reporting results. See review and maintenance for recurring checks and issue handling for tracking remediation.

Define what belongs in the register

Start with the public domains and applications people use for BuildLACCD information and services. Add page templates and interactive journeys, public document libraries, recurring document families, media collections and third-party tools embedded in or linked from those journeys. Identify ownership across the whole process, including a supplier that controls a registration, map, survey, video player or hosted document viewer.

Use a sitemap, analytics, known service list, editorial calendars, procurement records and staff interviews as discovery inputs. A crawler or file list can help locate content but will miss pages behind forms, changing page states, password-protected workflows and some externally hosted material. Record the discovery method and the date. Keep a boundary field for items that need scope confirmation instead of assuming they are excluded.

Reconcile the register each month against new page requests, releases, file uploads, vendor renewals and user reports. Assign a named role and backup for each item. Review high-impact or rapidly changing services more often when there is a confirmed need.

Record details for planning and retesting

• Inventory ID; public name; canonical URL or service entry point; content or service type; primary user task.
• Owning team and content owner; technical owner; supplier name and support route; renewal or change window when known.
• Platform, template or component; source repository or editable file location; production and test environment.
• Accessibility target and scope decision; last review date and method; known findings and linked issue IDs.
• Feedback route, public statement location, next planned review date and reason for priority.
• Status: active, replaced, archived, pending scope decision or retired; change record and approver.

A useful record lets a maintainer identify which shared component or supplier needs to be checked after a change. Store internal contacts in the approved system and publish only the approved public contact information.

Connect suppliers to the affected user task

For each third party, record its purpose, where people encounter it, information handled, procurement owner, supplier contact and change-notice method. Note whether a usable alternative exists. Request current accessibility documentation with its scope, date, methods and product version. Arrange a demonstration or test access for the full user journey.

Test the integrated service in BuildLACCD’s page, configuration and complete process. Assign an internal owner to reproduce barriers, file supplier issues, track decisions and retest updates. When a service changes or is replaced, preserve migration and record requirements, update links and staff instructions, and revise the inventory.

Escalate a service with no owner, no working test route or a barrier that blocks an important task to the program owner and procurement contact. Keep it in the register while a decision is pending. See third-party content for on-page integration checks and the document library guide for downloadable files.

Define the task and interaction states

Before design or build work starts, record the task the visitor must complete, affected pages, user groups, content type and every state of the interaction. Include empty, error, success, expanded, modal and responsive states where relevant. Confirm what content meaning must remain available and which team owns the labels, instructions and alternative text. Check the design against the current shared pattern before introducing a new component.

During design review, inspect reading order, headings and labels, keyboard sequence, focus visibility, error and status messaging, contrast, zoom and reflow. Identify any motion or gesture that needs an alternate interaction. Give design feedback while changes remain inexpensive. For background on specific patterns, use the existing guides for forms, tables and page structure.

Check the implemented component in realistic content

On a staging or approved test environment, test the actual code with realistic labels, long text, errors, repeated content and small-screen layouts. Run automated checks on changed pages and representative examples of every template that uses a changed component. Record tool name, version, ruleset, URL, date and result. Confirm flagged issues instead of copying scanner labels into the release record without investigation.

Manually complete the intended task with a keyboard, visible focus and increased zoom. Check text resize and reflow at narrow widths. Use an appropriate screen reader for changed controls, names, relationships, status announcements and form results. Test the browser and assistive-technology combinations that the review scope names; mark untested combinations explicitly. An empty component or isolated screenshot is not enough when content changes the layout or meaning.

Document each defect with location, state, steps to reproduce, impact, assigned owner, proposed correction and target date set by the responsible owner. Shared components need a regression check in the representative pages that depend on them.

Record the release decision and verify production

Hold publication until the Reviewer records the scoped checks, recommendation, unresolved issues and authorized decision. Label each untested case. If District policy permits a formal exception, record the authorized decision-maker, rationale, affected users and task, accessible alternative, owner and review date; the checklist itself grants no exception authority.

After deployment, open the public page while signed out and repeat the key task. Confirm the live component, correct document, links, labels and confirmation state. Keep a recovery reference for technical releases. If a production barrier appears, notify the Reviewer, record an issue, and repair or roll back under the approved recovery plan.

See review and publish a website update for the editor handoff.

Use a cadence that fits ongoing work

Approve and resource this proposed local cadence. Increase frequency when a service changes often, has a serious known barrier or supports a time-sensitive task.

• Weekly quick review: during active publishing, check upcoming releases, newly reported blockers, urgent notices and progress on assigned fixes.
• Monthly thorough review: review open issues, changed pages and files, links, event content, scanner results and overdue manual checks.
• Quarterly manual review: choose representative templates and complete key tasks with keyboard, zoom and appropriate assistive technology. Include interactive states and a sample of documents and third-party services.
• Annual evidence review: review the inventory, evaluation scope, findings, remedies, training and resource decisions; issue a report with methods, limitations and actions for the next cycle.

For a skipped or deferred review, record the reason, owner and new date. Save completed results with the review record.

Select a sample and test complete tasks

Use the inventory to group pages by template, content pattern, interaction and risk. Include recently changed or frequently used journeys, known problem areas, and a varied sample of documents and media. Explain why the sample represents the stated scope. Include an additional random sample when feasible to detect issues outside the obvious high-risk pages.

For each selected item, define the start point, expected task, interaction states and observable success. Test keyboard reachability and order, focus, labels and instructions, error recovery, zoom and reflow. Use a screen reader for relevant structures and changes in state. For a document, inspect the final published copy. For a process, test from start to completion because problems may appear between pages or inside an embedded service.

Use automated checks to identify code patterns, then verify findings and manually assess content and complete user tasks. Record cases the tools cannot evaluate and request specialist review when needed. When practical, include people with disabilities in usability work; the responsible program should arrange preparation and compensation.

Record results and their scope

A monitoring record includes review ID, date, reviewer role, scope, sample selection reason, URLs or file versions, environment, browser and assistive technology, test steps, expected result, observed result, evidence link and related issue ID. For automated checks, add tool version, ruleset, configuration, raw output and reviewed findings. Keep personal information out of general reports.

Report the size and nature of the sample, methods used, criteria checked, exclusions and open findings. Label results with the reviewed sample and date. An annual evaluation should be planned by people with suitable accessibility expertise and can follow WCAG-EM’s process for scope, exploration, sampling, evaluation and reporting.

Compare results over time only after accounting for inventory or sample changes. Route defects into the issue register and verify fixes with the original steps. See quick checks for an editor-level test and maintenance guidance for release retesting.

Respond to the task and route

When someone reports a barrier, ask what they are trying to do and what help would work for them. Start with the task description and request only details needed to respond. Confirm a safe reply route for follow-up, and collect only task-relevant personal information.

The District should confirm which public channels are monitored, who checks them, the backup, the approved response expectations and how reports are routed outside business hours if that matters to the service. Do not publish an unmonitored email or promise a response interval that has not been approved. If the usual contact route itself is inaccessible, staff should use the approved alternate route and tell the Accessibility lead so the channel can be fixed.

Keep sensitive contact details in the approved private system. Public release notes should describe the issue and repair without exposing a requester’s identity or circumstances.

Create a record that enables repair

• Issue ID, discovery date and source, page or file URL, document version, service and affected interaction state.
• Task the person was attempting, barrier observed, impact, deadline and any affected audience or service.
• Reproduction steps and environment if known; mark unknown details rather than blocking intake.
• Assigned content, technical or supplier owner; urgency decision; next action and owner-confirmed target date.
• Assistance offered, requester preference where relevant, privacy handling and communication status.
• Repair, deployment and retest results recorded separately, including reviewer and evidence location.

Prioritize by whether people are blocked, task consequences, time sensitivity, breadth of impact and availability of a safe alternative. Treat scanner severity as one input; assess user impact directly. Escalate high-impact barriers promptly to the service owner and Policy approver.

Provide assistance and verify repairs

While a repair is underway, offer a usable path such as an accessible web version, corrected document, staff-assisted completion or another method. Preserve the essential information, deadlines and opportunity to participate. Confirm that the route works for the immediate task, including with the person when possible.

Track alternative access separately from remediation of the original page or file. Recording an issue does not waive repair. Any formally permitted exception or risk acceptance must follow District authority and process, and include affected scope, rationale, user impact, available alternative, accountable approver and review date.

Close an issue only after repeating the reported task against the deployed fix, recording the result and checking related pages or shared components as appropriate. If the fix is partial, the supplier has only acknowledged a ticket, or the alternative has not been verified, keep the record open. Where the requester asked for follow-up, provide a clear status through the approved channel. See barrier reporting guidance and third-party content checks.

Choose the format before authoring

Define the user task, audience, review date and document owner before preparing a file. Put information, instructions and short notices in HTML when the web page can serve the task well. Use a downloadable format when it adds a real benefit, such as an official record, a printable worksheet or a complex reference. Keep an editable source so the next revision does not begin with repairing an old export.

Prepare structure, headings, tables, link labels, image descriptions, language and reading order in the source application. For video and audio, plan captions, transcripts and descriptions for meaningful visual information before recording or publishing. The Content owner approves meaning and accuracy; the Reviewer checks structure and delivery.

See Word documents, PDFs, video and audio and document libraries for format-specific checks.

Review the final asset in its page context

Before publication, compare the final file or media with the source and intended page. Check title, language, content order, headings, labels, table relationships, links, captions or transcript, and download or playback behavior. Use keyboard and assistive-technology checks for interactive PDF fields or players. Manually inspect the final asset against its intended task, including when export or automated checks pass.

The reviewer confirms that the page label identifies the title, format and current revision. The content owner verifies that the file is current and that any required companion format is available. After upload, test the real public link and confirm it opens the intended version. If content is time-sensitive, record an expiration or review date so stale information can be removed or marked clearly.

Revise, archive and replace files

When the source changes, increment the revision, repeat relevant document and media checks, update the landing page and inspect direct links. For a replacement, confirm which version is current and whether older copies must be retained as records. Label archived files as superseded and avoid leaving several files that appear current. Preserve the prior version in the approved records location when retention rules require it; do not overwrite official records without the records owner’s direction.

If a source is lost or a complex file cannot be repaired safely, request specialist support. Provide the source candidate, published copy, findings, intended user task and needed date. If an accessible replacement is delayed, coordinate an interim route with the service owner and record the remaining barrier. Update the inventory with the current URL, owner, version and next review date.

Schedule practice for each role

Before scheduling, confirm participants, accommodations, a session facilitator, format and work time with the responsible manager. New staff should attend the relevant session before publishing public content. Repeat or update instruction when a CMS, component, workflow or standard changes, or when recurring findings show a skill gap. The sessions below are a proposed curriculum, not a training record.

• Content editor lab, 75 minutes: 10 minutes on task planning; 20 minutes repairing headings, links and image alternatives; 20 minutes reviewing a document or media item; 15 minutes checking the preview and recording the result; 10 minutes on handoff and issue reporting.
• Reviewer lab, 90 minutes: 15 minutes on scope and evidence; 25 minutes keyboard, focus and zoom checks; 20 minutes content and document review; 20 minutes issue writing and retest; 10 minutes on release decisions and escalation.
• Accessibility lead and Website team lab, 120 minutes: 20 minutes on inventory and sampling; 25 minutes on automated results; 35 minutes on component and complete-task manual tests; 25 minutes on issue ownership and supplier handoff; 15 minutes on reporting and regression evidence.

Adjust session size or duration for the participant group and the complexity of the actual tools. Use the production-like training environment and approved sample materials.

Practice the work each role performs

Give editors a draft page containing a vague heading, an ambiguous download label, a meaningful project image and an event flyer whose essential details need HTML text. Ask the participant to revise the page and explain the choices. Give document authors a source file with a real heading structure and table, then ask them to produce and inspect the published version. Reviewers can test a form’s keyboard path, identify an error that traps a user and write an issue record. Accessibility leads and the Website team can triage a scanner result, reproduce a finding and record a retest after a sample fix.

Use synthetic or approved public content. Do not place personal, student or confidential information into shared training files. Provide the instructions and exercise materials in an accessible format and let participants use their preferred assistive technology.

Assess skills and record training

Score the practical exercise with a simple observable rubric. Use “demonstrated independently,” “demonstrated with a prompt” or “needs follow-up” for each task. The reviewer checks whether the participant: (1) chooses the correct content guide; (2) makes a meaningful correction without breaking structure; (3) completes the user task with the assigned check method; (4) records an actionable result; and (5) routes specialist or policy decisions to the right role. Do not convert this learning rubric into a WCAG score or employee rating.

Offer focused follow-up for any task marked needs follow-up, agree an owner and date with the manager, then repeat the task. Record session ID, date, facilitator, role group, materials and version, participants or attendance reference, a private support-case reference if needed, exercise result, follow-up and next refresh date. Keep attendance and individual learning notes in the approved training system with its access and retention controls.

Include supplier and developer roles when their work affects covered services. If the District determines a role does not apply, document who made that determination and why. See roles and responsibilities and publishing workflow.

Define service scope and accessibility needs

Before issuing a solicitation, renewing a subscription or accepting a vendor-built component, write down who will use the service, the tasks it supports, the data and documents it creates, and how it connects to existing pages. Include public and staff-facing steps when they affect the service. Identify whether people use the service with keyboard, screen reader, magnification, speech input or other assistive technology, and determine who can evaluate those flows.

Ask for the current accessibility conformance report or equivalent product documentation, including the product name and version, assessment date, methods, tested scope, known issues and contact for accessibility follow-up. Ask how the supplier tests updates, not only how the original product was assessed. Use supplier documentation and scans to shape the review, then test the intended configuration and complete user task directly.

Include accessibility requirements in the solicitation and contract review process through the District’s authorized procurement and legal teams. This guide is operational support and does not supply legal clauses or substitute for contract review.

Demonstrate the workflow before selection

Prepare representative scenarios from the service owner’s task list. During a demonstration or test, navigate with keyboard alone, inspect visible focus, use zoom and narrow the viewport, complete forms with errors and correction, and use a screen reader for important controls and status changes. Test any embedded service in the actual integration where possible. Ask the supplier to show how captions, transcripts, labels, error messages and user help are maintained by administrators.

Keep a question log with response, evidence link, reviewer and unresolved concern. Evaluate risk by task impact, scope, ease of obtaining a complete test, supplier remediation path, change notification and a viable alternative. If a scorecard is used, define its scale before comparing suppliers and keep the underlying evidence visible. Label any scorecard as a procurement aid, not a conformance or maturity result.

Make acceptance and renewal testable

Before acceptance, confirm the product version, configuration, integration, tested tasks, unresolved findings, owner, remediation path and acceptance decision. State which aspects were tested and which remain unverified. Assign an internal service owner who will monitor vendor changes and public feedback. Record supplier escalation steps and how urgent barriers are handled under the approved service process.

At renewal, review new versions and configuration changes, new user feedback, open vendor tickets, accessibility documentation updates and the internal inventory. Retest after a major release or when a reported barrier affects the service. Keep a fallback or transition plan where the service supports an important public process. If no acceptable path is available, escalate the decision to the program owner and authorized procurement or policy decision-maker before expanding use.

Close a supplier issue only after retesting the integrated service. See third-party content and the inventory and vendor register through the operations collection.

Include access needs in event planning

At event intake, record the program owner, purpose, audience, venue or platform, registration method, date, publishing deadline, content formats, caption or interpretation needs and a contact route that has been confirmed as monitored. Ask what participation options are needed without asking attendees to disclose a diagnosis in public. Route accommodation details through the approved private process.

Before sending an invitation, publish the essential information as page text rather than only in a flyer. Include date, time zone, location or access instructions, registration steps, accessibility information and a working link with a meaningful label. Confirm the form works by keyboard and at increased zoom, and test the confirmation or cancellation steps. Use the guides for events and flyers and forms and registration.

For live or recorded media, decide who will prepare captions, transcripts and any description of meaningful visual information, when they will be reviewed and where the accessible materials will be published. Confirm that speakers’ slides and handouts arrive in time for review.

Check access before, during and after the event

Before the event, verify the public page, registration journey, venue or joining instructions, media controls, access contact and event materials. Confirm that suppliers and presenters know their assigned tasks. During the event, give attendees a way to report a participation barrier and assign someone to receive and route it. Avoid making a person repeat access information in front of the group.

Afterward, publish captions or a transcript when appropriate, check the recording and linked materials, and review feedback for follow-up. Log barriers and improvements without publishing private information. If a public recording or document is replaced, update the event page and preserve the current version details.

Set an internal accessibility communication plan

The Content owner proposes an audience, schedule and resource needs for recurring messages, then seeks District approval. A starting plan is a monthly editorial update on current barriers, changed guidance and upcoming work; a quarterly invitation to role-based practice or refresher training; an annual summary of the improvement plan and results; and a targeted notice when an owner, tool, approved procedure or assistance route changes. Set intervals for the approved audience and covered teams.

For each message, record audience, purpose, owner, approved channel, scheduled date or trigger, accessible format and review responsibility. After distribution, retain the exact version, date, intended recipients and available delivery confirmation. Review feedback and missed audiences at the next program meeting. Track completed distribution separately from scheduled messages.

Teach new staff the actual publishing route

For each staff role, onboarding should identify the approved request route, required owner and reviewer, accessible templates, guide links, test environment, evidence location and help escalation. Give new editors a short practice task using sample content before their first high-impact publication. Explain where public-facing feedback is routed and how urgent issues reach the responsible owner.

Record onboarding date, role, materials version, practice task, result, follow-up owner and date. Check access to approved tools and templates with the manager. When a person changes roles or a publishing tool changes, update their training and permissions through the normal internal process. Record practice results and check that the production workflow is in use.

Each quarter, compare scheduled communications and events with published pages, accessibility requests and open issues. Use recurring problems to update templates and training. Add decisions to the monthly or quarterly governance review so that communications and event owners can request needed resources before deadlines.

Prepare and facilitate the session

Use fictional sample content throughout this lab and label every output “Training exercise.” Assign someone to facilitate; prepare a staging or local editor, this guide and the blank training record. Send instructions in advance and confirm participants can use their preferred assistive technology. A participant without editing permission may describe a proposed fix.

Follow the 75-minute editor lab in the role-based training procedure: 10 minutes to define the task; 20 for the page exercise; 20 to choose and check an approved document sample; 15 to preview and complete a release record; and 10 for questions and handoff. Select a source file and exported PDF before the session. Record any segment that remains incomplete.

Exercise 1: Rewrite a flyer as page content

Fictional brief: An information session about a proposed construction project is scheduled for November 18, 2026, from 2–3 p.m. Pacific time, in Example Hall, Room 101, 100 Example Avenue. The flyer contains these details and says registration is optional. It includes a QR code for the project information page. The organizer has not yet confirmed an accommodation contact or venue access details. A diagram shows a main entrance on the south side and a step-free route from the east entrance to Room 101.

Draft supplied to the editor:

<h4>More info</h4>
<p>See the flyer below for details.</p>
<img src="session-flyer.png" alt="flyer">
<p><a href="session-flyer.pdf">Click here</a></p>

1. Write a clear page heading and the essential event details as HTML text.
2. Decide whether the flyer adds information once the text has been written. Explain the image alternative you would use.
3. Write a meaningful label for the PDF link and explain what must be checked before linking it.
4. Describe the route shown; leave venue access confirmation to the owner.
5. List what still needs owner confirmation. Prepare a release record with those items open.

Keep this example in training. Leave the accommodation contact and venue access details open for confirmation; link only to a checked file and verified destination.

Answer guide for facilitators

Start with a descriptive top-level heading such as “Construction project information session.” Put the date, time zone, address, room and optional-registration status in page text. Link the QR destination with an ordinary text link after verifying its URL. If the flyer repeats adjacent information and is not a link, an empty image alternative may fit; include any unique useful information in the page or an appropriate alternative.

Label the download “Construction project information session flyer (PDF).” Add file size only when confirmed. Check the source and final PDF for tags, language, reading order, meaningful images and links; remediate the PDF itself where needed.

Describe the diagram’s south entrance and the step-free route shown from the east entrance to Room 101. The organizer confirms the real route and assistance contact before approval. The release record should name the fictional scope, checks, open confirmations and reviewer, and remain marked as a training exercise.

Exercise 2: Record a reproducible test result

Use a staging page supplied for the lab, or this microsite’s publishing checklist as the practice target. State the scope and environment. Use keyboard only to choose a document update, reach generated checks, mark an item, enter a page title and download a review record. Repeat at increased zoom. If screen-reader testing is in scope, complete the task with the assigned browser and screen reader; record their versions.

Record what happened, including passing results. For an observed barrier, capture its location, expected and actual behavior, reproduction steps, user impact and environment in an issue record. Ask another participant to reproduce it from the record alone. Mark untested combinations. Download a practice release record and identify where the corresponding District record would be retained.

Exercise 3: Identify evidence gaps

Fictional evidence set: a completed draft procedure, a blank owner field, an invitation for next month’s training, one past automated scan with no manual results, and a supplier email saying “fixed” without a retest. Ask the accessibility lead to identify existing records, unperformed activities and evidence needed for assessment review.

Expected reasoning: the draft supports documentation; owner and resource decisions remain open. Compare the invitation with delivery and demonstrated skill. Note the scan’s date and scope and identify missing manual tests. Retest the supplier fix in the integrated service before closure. Create an evidence-review record that lists the five evidence dimensions separately and assigns follow-up decisions. Do not change accepted ratings in this exercise.

Record skills and follow-up

For each participant, rate five observations as “demonstrated independently,” “demonstrated with a prompt” or “needs follow-up”: choosing the right guide, making a meaningful correction, completing the assigned task, writing a reproducible record and routing decisions to the right role. Note untested skills. Record demonstrated skill; attendance alone does not complete the exercise.

Download the training record with the actual session date, materials version, attendance reference, observations and follow-up owner/date. Mark practice records “Training exercise.” Agree and record another practice opportunity for any skill needing follow-up, including the next session or onboarding trigger. Use this rubric to plan learning follow-up; it does not assess WCAG conformance or ACMM maturity.

Decide what the image contributes

Write alt text after you know why the image is on this page. A project photograph may identify a visible milestone, a portrait may identify a speaker, and a campus map may need a longer explanation elsewhere. The same file can need different alt text in different contexts. Use the image’s purpose, not the filename or camera metadata, as your starting point.

• Informative: describe the essential subject or message briefly.
• Decorative: leave the alternative empty when the image adds no information beyond nearby text.
• Functional: describe the destination or action when an image is the only content of a link or button.
• Complex: provide the key information in nearby HTML or a linked text equivalent, rather than trying to fit a report into one short sentence.

Do not mechanically begin every alternative with “Image of.” Assistive technology already identifies an image. Include that word only when it helps distinguish a photograph, illustration, or other medium.

Write and review it in the editor

In the media item or image component, enter a concise, specific alternative. Name people only when their identity is relevant and confirmed. Include location, action, or visible result when it helps someone understand the surrounding story. Keep the visible caption and alt text complementary: a caption can provide photographer credit, date, or broader context, while alt text covers what a person who cannot see the image needs for this page.

If an image contains words that are not repeated as real HTML text, do not rely on the image alone. Put the information in the page copy and use a shorter alternative that points to that context. Avoid putting event dates, registration instructions, or report findings only in a graphic.

Use the alt-text example tool to compare a draft alternative with the page context before publishing.

Know when to request a handoff

Ask the website maintenance team to review charts, maps, diagrams, image links, and any image that opens a gallery or lightbox. A chart needs its data or conclusion in text; a linked image needs a reliable accessible name; and a decorative background must not hide information. The developer should confirm that the rendered image has the intended alternative, that the alternative is not duplicated by an adjacent link label, and that the image remains understandable at zoom.

Prepare the story before uploading

Start with a useful gallery title and one or two sentences explaining what viewers will see, where, and why it matters. Choose an intentional order. Remove near-duplicates unless the change between them is part of the story, such as construction progress. Give each meaningful photograph its own alternative that reflects its role in the sequence. A visible caption can carry date, credit, or a more detailed note, so it does not need to repeat the alternative word for word.

When several images together communicate one idea, explain the idea once in nearby text and avoid making screen reader users hear the same description repeatedly. If an image is only a repeated visual detail, mark it decorative in the authoring tool when that is available.

Publish the editorial details

For each image, check the alternative, caption, credit, and any date or location against the source material. Do not put a full event notice or project update inside a photograph. If people are identifiable, follow the project’s approved photography and naming process; accessibility guidance does not create permission to publish personal information.

A static set of images is often easier to understand than an auto-advancing carousel. If a carousel is required, provide visible previous and next controls, a way to pause movement, a clear current-item status, and a predictable way to reach every image. Keep controls comfortably separated. WCAG 2.2 requires most targets to be at least 24 by 24 CSS pixels, with exceptions such as spacing, equivalent controls, inline links, unchanged user-agent controls, and cases where a particular presentation makes that target size essential, such as a dense map or data visualization, or where a legal requirement constrains it. A 44 by 44 CSS pixel control is a useful design practice for gallery buttons, especially on touch screens.

Hand off interactive behavior

Send the gallery URL and a short content checklist to the developer when it uses a slider, modal lightbox, lazy loading, or custom controls. The rendered component should have meaningful names and roles, a visible focus indicator, logical focus order, and a keyboard path to open, move through, and close the gallery. When a lightbox opens, focus should move into it and return to the launching control when it closes. The expected user outcome for a modal dialog is that Escape closes it; the developer should implement that behavior consistently and preserve focus return. Test at zoom and with reduced motion enabled. Keep an accessible fallback or page-level text so a script failure does not erase the story.

Put the event facts in HTML

Write a page heading that names the event, followed by a short description and a clearly labeled list of details. Include the date, start and end time, time zone when the audience may be remote, venue or online location, audience, cost if applicable, registration deadline, and the purposeful registration action. Add access information that has been confirmed for this event. If an event changes, update the HTML details first and then update or replace the supporting flyer.

• When: Wednesday, October 14, 2026, 10:00 a.m. to 12:00 p.m. Pacific Time
• Where: Campus auditorium, with an online attendance option
• Registration: Registration closes October 10

Use the same date and time wording in the page title, registration instructions, and any supporting graphic. Spell out the month and include an end time when the event has one. If registration requires a separate process, state what the person will need before they follow the link. This reduces the need to interpret a poster or guess which “Register” action is current.

Use the event-copy example tool to check whether the notice still works when the supporting flyer is removed.

Use the flyer as supporting content

If a designed flyer is important to the campaign, publish it after the same information appears as text. Give the image a concise alternative that identifies it as a flyer and conveys its purpose, not every line of small type. If the flyer contains unique instructions, reproduce those instructions in HTML or provide an accessible document equivalent. Avoid text embedded in images for information that people need to copy, search, translate, or enlarge.

Check contrast and legibility at normal zoom before publishing. Do not use color, font size, or placement alone to communicate that an event is canceled or that registration is required. Use a real heading, paragraph, list, or status message as appropriate.

Coordinate updates and technical review

Give the reviewer the source facts, approved event owner, and expiry or update date. The editor owns accuracy of the facts and links. If the event owner provides a verified accommodation contact, publish the approved office or person, contact method, and response deadline in HTML near the event details. If no contact is confirmed, ask the event owner to supply one rather than guessing. A developer should confirm that the event information is real text in the page structure, links have clear names, the flyer has the intended alternative, and the page remains usable when text is enlarged or the image fails to load. For event registration, hand off the form interaction separately; a correct announcement does not guarantee an accessible registration flow.

Outline before you edit

Start with the page’s established title and template. Use one clear content title unless the template or a developer confirms a different structure. Break the page into meaningful sections, then nest subsections under the section they belong to. A heading with rank 2 can introduce a major section, and rank 3 can introduce a subsection inside it. Do not choose a heading because its font looks right, and do not skip from H2 to H4 simply to make text smaller.

Headings should identify the subject of the section. “Project timeline,” “How to register,” and “Download the quarterly report” are more useful than “Overview,” “More information,” or a row of decorative words.

Use the editor semantically

In WordPress, use a Heading block and choose its level from the block controls. The editor’s document outline can help you review the sequence. In Elementor, the Heading widget’s HTML Tag field controls whether the text is an H1 through H6 or a non-heading element; changing that tag does not have to change its visual styling. Set the semantic level first, then apply the approved visual style.

Write short paragraphs, front-load the important noun or action, expand abbreviations on first use, and explain a specialized project term when the audience may not know it. Use lists for steps or requirements, and use link text that still makes sense when read out of context.

Keep the first sentence useful on its own, especially when the page is summarized in search results or a card. Prefer “Submit a comment by Friday” to “We would like to remind stakeholders that comments may be submitted.” Preserve the project’s approved terminology, but add a plain-language explanation when a technical term cannot be avoided.

Hand off template and component questions

Ask a developer to review the heading structure when a page builder, reusable component, sidebar, accordion, or card grid adds its own headings. The fixed navigation and footer may use a consistent rank across pages, while the main content needs to retain a readable outline. The developer should inspect the rendered HTML, not only the editor view, and check that text remains visible and ordered at zoom and on small screens. If the page has no usable main title or generates multiple competing titles, stop and request a template decision.

Write purposeful link text

Link the words that describe the destination or action. A person scanning only the links should be able to tell which report, registration form, project page, or external service each one opens. “Read the 2025 project delivery report” is clearer than “Read more,” and “Register for the community briefing” is clearer than “Click here.” Nearby sentence or list context can add meaning, but do not make people reconstruct it from a long page.

Do not use a raw URL as the only description when a readable title is available. If several links point to the same destination, consider combining adjacent image and text links so keyboard and screen reader users do not encounter duplicate stops.

Describe downloads honestly

For a file link, include the document title and, where useful, its format and size in the visible wording. Format and size are editorial recommendations that help people decide what will open and how much data is involved; WCAG 2.2 Success Criterion 2.4.4 requires a discernible purpose in context, not a particular “PDF” or megabyte suffix. The file itself must still be accessible. A link to an inaccessible PDF is not fixed by adding “PDF” to its label.

Use the approved document title, verify that the link resolves, and check whether a newer version has replaced the file. Warn people before opening a new window or external service when that behavior is necessary. Do not quietly add a new-tab behavior to every link.

Use editor controls and request review

In WordPress, select the descriptive text and use the Link control to add or edit the destination. Review the visible wording after the link is inserted; do not leave a filename or tracking string as the label unless that is genuinely the destination’s name. For icon-only links, ask the developer to confirm the accessible name and visible focus state.

Send the developer a list of links that open new windows, trigger downloads, launch maps, open media, or depend on JavaScript. The rendered link should be keyboard reachable, have a visible focus indicator, and expose its purpose and state. Ask the document owner to review the linked file under the standard that fits its format and delivery context. WCAG also applies to web documents delivered online; PDF/UA provides format-specific PDF guidance, and WCAG2ICT provides complementary guidance for non-web documents and software. These standards work together rather than replacing one another.

Choose a table for data

A table is appropriate when people need to compare values across rows and columns, such as project milestones by campus or meeting dates by location. It is not a layout tool. If the content is a sequence of instructions, use headings and lists instead. Before building the table, decide what each row and column represents, write a short caption that names the subject, and identify the units and reporting period.

Mark a simple table’s structure

In WordPress, use the Table block’s caption and header-section options when they match the data. Mark the first row or column as a table header in the editor. Keep labels concise and consistent, include units in the heading or caption, and do not communicate meaning only through color. Check that the table remains understandable when viewed at high zoom and on a narrow screen.

For simple row and column relationships, the underlying HTML should expose a caption, header cells, and data cells. A person using a screen reader should be able to move through a cell and understand which row and column headings apply. If the page builder cannot produce that structure, provide the data in another accessible form and request a developer review.

When custom HTML is involved and rows and columns both act as headers, use scope="col" for column headers and scope="row" for row headers. A developer should verify the rendered markup, especially if the editor or a table component transforms the table.

Check the source before publishing. Remove blank spacer rows, repeated heading rows, unexplained abbreviations, and decorative symbols that carry no data. Put notes about rounding, missing values, or a preliminary status directly before or after the table. If a value is unavailable, use a consistent text value such as “Not reported” and explain it, rather than leaving an empty cell that could be mistaken for zero.

Read the table aloud by following one row from its first heading through its values. If the relationship is difficult to explain in a sentence, simplify the table or add a short introduction. Do not assume borders, alternating colors, or centered numbers are enough to tell someone which value belongs to which category.

Hand off complex and responsive tables

Ask the developer to review tables with grouped headers, merged cells, multiple header levels, sortable controls, or horizontal scrolling. Complex relationships may need explicit header associations in the rendered HTML. The responsive design should preserve the relationship between each value and its headings; shrinking text until it becomes unreadable is not a solution. For a large report, consider a concise HTML summary plus an accessible document or data download that has been reviewed separately.

Design the content and instructions

Start by listing the minimum information needed to register or complete the request. Use a visible label for every field and put the label above or beside its control. A placeholder is a hint, not a replacement for a label. Explain required fields, accepted formats, dates, character limits, and what happens after submission before the person starts. Group related choices with a clear question and keep the order predictable.

Keep registration steps short where possible. If a long process must be split into pages, name each step and show progress without making people guess what will happen next.

Tell people what information is optional and whether they can save and return later. Avoid asking them to repeat information that was already entered. If an upload is required, state the accepted file types and a size limit in advance, and provide a text alternative to any instruction shown in a sample image.

For recognized personal-data fields such as name, email, phone, or address, give the developer the field purpose so the rendered control can expose an appropriate autocomplete token. Within the same multi-step process, reuse information or let people select it instead of asking them to retype it, unless re-entry is essential, needed for security, or the information is no longer valid. For authentication, request that password managers and paste remain allowed. If spam protection uses CAPTCHA, ask the developer to review its alternative and test the complete path.

Plan validation and confirmation

Write error messages that identify the field and the correction, such as “Enter a date in MM/DD/YYYY format.” Keep the person’s valid entries when validation fails. Provide a summary for multiple errors and place it where keyboard and screen reader users can find it. After success, confirm what was submitted and what happens next. A change in the page, an error summary, or a success message must be announced or brought into the user’s path by the implemented form behavior.

If the site uses Gravity Forms, its official accessibility guidance recommends visible labels, meaningful custom validation messages, and the built-in error-summary approach. Review the form’s current settings and version rather than assuming a default makes the entire flow accessible. Never hide required information in color alone.

Hand off interaction and data behavior

Ask the developer to test the complete flow with keyboard only, zoom, and a screen reader. Verify label-to-control associations, focus order, visible focus, grouped choices, date pickers, upload controls, error focus, status announcements, and the success path. Controls should be comfortably sized. WCAG 2.2’s 2.5.8 minimum is 24 by 24 CSS pixels with exceptions for spacing, equivalent controls, inline targets, unchanged user-agent controls, and cases where a particular presentation makes that target size essential, such as a dense map or data visualization, or where a legal requirement constrains it. Aim for 44 by 44 CSS pixels for primary controls where practical.

Avoid time limits in registration when possible. If one applies, implement the WCAG adjustment or extension options, or document a valid criterion exception and how users can complete the task. Ask the process owner to review confirmation, retention, and privacy wording. Accessibility review does not approve collection of data or create a policy.

Start with structure, not decoration

Write the outline before polishing the page. Give the document one descriptive title, then apply Word's built-in Heading 1, Heading 2, and Heading 3 styles in a logical order. A larger bold paragraph is only visual formatting; it does not create a navigable heading for a screen reader. Keep each heading specific enough to make sense in a list of headings, such as “Meeting agenda” or “Submit a project safety report,” rather than “Overview.”

Use real numbered and bulleted lists, not lines that begin with typed hyphens or numbers. Use a simple data table only when a table communicates relationships that prose cannot. Give it a header row, avoid merged or split cells, keep the layout flexible, and do not place a complete page layout inside a table. Put important information in the document body instead of hiding it only in a header or footer.

Make visuals, links, and color carry their meaning

Add alt text to an informative photo, chart, diagram, or screenshot. Describe the purpose and the information a reader needs, not every visible detail. Mark a purely decorative image as decorative. If a graphic contains essential words, repeat those words in nearby text instead of making the image the only copy. Use descriptive link text that still makes sense when someone scans links out of context: “Download the 2026 design standards (Word)” is useful; “click here” is not.

Do not communicate an approval state, deadline, or safety condition with color alone. Add a word, symbol with a text label, or a heading. Check contrast for text and meaningful graphics, avoid excessive all-caps and italics, and leave enough white space for zoom and magnification. Before exporting, accept or resolve tracked changes and comments that should not be public, and make sure the final filename and document title identify the same publication.

Use the checker that matches your Word version

Microsoft documents the Accessibility Checker for Word on Windows, macOS, and the web, although command names and their locations can differ. In desktop Word, look under Review > Check Accessibility or use the accessibility status message. Word for the web exposes the same goal through its accessibility tools while you edit online. The newer Accessibility Assistant described by Microsoft is currently a Windows-only Word feature, so do not assume a Mac or browser user will see the same pane.

1. Run the checker on the final draft and open every result, including warnings and tips.
2. Fix the source: apply a heading style, add alt text, simplify a table, or rewrite a link.
3. Save, close, and reopen the file. Check the Navigation Pane, zoom to 200%, and move through the document with the keyboard.
4. If the document will become a PDF, export from the structured source and continue with the accessible PDF checks; a Word checker result does not certify the PDF.

Know when to hand off

Ask an accessibility specialist to review a complex form, multi-level table, chart with a dense data story, diagram with relationships, template with fields, or document that will be reused in many versions. Include the editable source, intended audience, output formats, and a short list of decisions already made. The reviewer should test the actual file with keyboard navigation and an assistive technology, not only inspect a screenshot.

Keep a small change note with the file: date, source application and version, checker results, manual tests, unresolved barriers, and the person responsible for the next review. That record makes the next meeting packet or report easier to repair without starting over.

Choose a structured source and export it correctly

Start in the authoring file whenever possible. Use Word heading styles, real lists, simple tables, alt text, and descriptive links before exporting. Create the PDF with the application's accessibility or tagged-PDF option. Do not use a system print dialog or “print to PDF” workflow for a public report or form: it can flatten the visual page and lose headings, reading order, links, or form semantics. Keep the source file so a correction can be made once and exported again.

Run the source file’s Accessibility Checker first. Microsoft’s export route varies by application and version:

• Windows: save a copy in PDF format, open the save dialog’s options and enable document-structure tags for accessibility. Create bookmarks from headings when useful.
• macOS: choose PDF as the file format and select the option for electronic distribution and accessibility before exporting. This uses Microsoft’s online conversion service. Confirm that sending the document to that service is permitted, and review Microsoft’s warnings for protected files before proceeding.
• Word for the web: use the File menu’s PDF download option, under Save As or Export depending on the interface. Open the downloaded file and continue the review below.

These routes preserve structure; they do not establish conformance. If your application does not expose a tagged-export option, ask the document reviewer for an approved method.

Set a meaningful title and primary language, a sensible opening view, and a stable filename. Do not use security settings that block assistive technology. For a long meeting packet or design standard, add bookmarks from document headings.

Build the tags and reading order

Tags are the PDF's structure tree. They identify headings, paragraphs, lists, tables, figures, and links so a screen reader can navigate a logical sequence. Inspect both the Tags panel and the rendered page. Verify two-column order and sidebar placement, and mark decorative lines and backgrounds as artifacts.

Give meaningful figures alternate descriptions, use table tags with header relationships, and add bookmarks to long reports. For a form, label each field, set its name, role, and required or optional state, include it in the tag tree, and set tab order to follow the instructions. A visible underline or rectangle is not a field label.

Inspect long reports, tables, and drawing packets

For a recurring export, fix the report template or export settings instead of manually repairing hundreds of pages every month. Give a long report a meaningful title, document language, page numbers, and bookmarks that follow its major sections. Test the table of contents, a representative narrative page, and the first page of each repeated layout. If the report is generated by a reporting system, ask its owner how tags, headings, table headers, chart descriptions, and bookmarks are produced.

Tables need real header and cell relationships, not only colored header bands. A chart or map needs a nearby text summary or data table when its message matters. For a drawing or signage packet, provide a text index with sheet or section number, title, discipline, revision, and purpose; do not make a color legend, logo, or image-only annotation the only way to understand the task. Keep detailed drawings for users who need them, but provide an HTML or text companion for the instructions and key decisions.

Check the PDF as a user

Acrobat Pro's Accessibility Checker or Full Check is a useful defect list. Resolve failures, inspect warnings, and read the report, but treat the result as evidence for follow-up rather than a compliance certificate. Automated checks cannot judge whether alt text conveys the right information, whether a table is understandable, or whether the reading order makes sense.

1. Inspect headings, lists, tables, figures, links, and artifacts in the reading order and Tags panels.
2. Tab through links and form fields; confirm visible focus, labels, order, and error instructions.
3. Use reflow and zoom as separate checks, then copy a sample page and compare extracted text with the visual page. Text extraction does not prove that reflow is usable.
4. Have a reviewer use a screen reader on a representative section and the main task.

PDF/UA, the ISO 14289 standard for accessible PDF, is distinct from WCAG 2.2. WCAG2ICT is an informative W3C Group Note for non-web documents and software. Treat it as supplementary, not PDF/UA certification or WCAG proof; document the evaluated target and scope. Continue with the repair guide if the source is unavailable or the exported file contains structural defects.

Hand off complex PDFs with evidence

Escalate a PDF with nested tables, charts that require a long description, scanned signatures, multi-column forms, embedded files, or a reading order that cannot be repaired reliably in the source application. Send the source, PDF, checker report, page numbers, and the intended task. Ask the specialist to return a repaired file plus notes that can be applied to the source so the next edition does not repeat the same defects.

Decide whether PDF is the right form

Ask the website team about an HTML form when the task needs validation, status updates, repeated submissions, or mobile use. A fillable PDF may suit an approved signature workflow or print-ready record. Agree the format with the form owner before changing an established process. Provide an accessible HTML or Word alternative when the PDF cannot support the task. A scanned page with blank lines is a static document, not a fillable form.

Start with the source file and the task instructions. Define each field's purpose, type, required state, allowed format, and what happens after submission. Group related questions and explain abbreviations before the user reaches the first field.

Label and structure every control

Use a real text label for every text field, checkbox, radio button, list, combo box, and button. In Acrobat, set a concise tooltip that says what to enter, not just an internal field ID. Use distinct field names, set the correct control type and required or optional state, and group radio buttons under one question. Include the controls in the tag tree and set the tab order to follow the visual and instructional sequence. W3C's PDF techniques call for interactive controls, labels, required-state information, and name, role, and value information.

Instructions must not live only in placeholder text, color, a symbol, or an underline. State the expected format before the field, such as “Project ID, 8 digits,” and give errors in text that identifies the field and explains how to fix it. Do not make a signature image or a drawn checkbox the only input mechanism.

Build from a tagged source and preserve the record

Prepare headings, lists, tables, figures, and link text in the authoring file, then export a tagged PDF. In Acrobat Pro, use Prepare Form or the form-field recognition tool as a starting point, then inspect and correct each field. Set the PDF title and language, allow assistive technology in security settings, and keep the editable source and a change note with the PDF.

For forms that will be reused, maintain a stable form ID and revision label in the file and on the landing page. If the form is signed or a record, preserve the original and publish a clearly identified accessible copy only through the responsible records process. Do not flatten an interactive form until the workflow explicitly calls for a static record.

Test the complete form task

1. Run Acrobat Pro Accessibility Checker or Full Check, resolve failures, and investigate warnings. This is a defect list, not a conformance certificate.
2. Use only the keyboard to reach every field, move between grouped controls, enter values, correct an error, and activate the submit or save action. Confirm visible focus and a logical tab order.
3. Have a reviewer use a screen reader to complete the representative task and confirm each field's label, role, state, value, and required instruction. An accessibility API or field-property inspection can support this review, but does not replace the user task. Reopen the saved file and verify values persist.
4. Check zoom and reflow separately, then compare a text extraction sample with the visual page. Check contrast, dates, numeric formats, calculations, and any conditional fields. Test the HTML, Word, or other alternative with the same task.

Ask for specialist review when the form has conditional logic, nested tables, signatures, complex calculations, sensitive records, or a high-consequence deadline. Record the file URL, form ID, revision, tools and versions, pages and fields tested, result, unresolved barrier, and next review date.

Publish with clear format and status

On the library page, give the form ID, title, confirmed revision or effective date, file type, size, and language. Say whether a PDF is fillable only after testing it. A useful label is “CP-0100 Request for Information (Word),” with the verified revision beside it. Do not call every form a PDF or use a row of links that all say “Download.” Offer the accessible alternative beside the PDF when available.

When a form changes, replace the canonical link deliberately, update the revision metadata, and check old direct links. Mark a retained prior edition as archived and not for current submissions. Do not silently leave multiple revisions that look current, and do not call a form accessible solely because an automated checker reports no errors.

Triage before touching the file

Make a working copy and record the filename, date, owner, source application if known, and why the document is still needed. Check whether text can be selected, whether the file is tagged, whether links and form fields exist, and whether the PDF is a scan. Then look for an editable Word, presentation, spreadsheet, or page-layout source. Repairing that source and exporting a fresh tagged PDF is usually more durable than repeating Acrobat touchups every edition.

Prioritize files that people must use to complete a task, such as a public form, a meeting agenda, a safety instruction, or a report with a deadline. Do not remove content or alter a signed record merely to make the page simpler. If the file is a record, preserve the original and create a clearly identified accessible copy according to the site's records process.

Repair in a logical sequence

1. Text: If it is a scanned PDF, run OCR and proofread the text against the page. OCR makes words selectable; it does not add headings, table relationships, correct language, or meaningful alt text.
2. Document settings: Set the title, primary language, and a security setting that does not prevent assistive technology from reading.
3. Structure: Add or correct tags, then inspect reading order. Mark decorative content as artifacts and apply heading, list, table, figure, and paragraph roles.
4. Meaning: Add concise alt text, create bookmarks from headings for long files, and repair link names and destinations.
5. Interaction: Label every form field, set required and input information, include fields in the tag tree, and make tab order follow the instructions.

Verify and log the repair

Run Acrobat Pro's Accessibility Checker or Full Check after structural edits. It can identify missing tags, alternate text, titles, language, tab order, and other likely failures, but a passing panel is not proof that the document is usable or conforms to WCAG 2.2 AA. Manually inspect every page type and every task the reader must complete.

• Read the Tags tree and a representative page with a screen reader.
• Use the keyboard to reach every link and field, and verify visible focus and order.
• Use reflow or zoom, copy a passage, and compare extracted text with the visual page.
• Check tables cell by cell, including header announcements and blank or merged cells.

Log the page numbers changed, the source and tool versions, checker results, manual tests, unresolved limitations, and the next review date. Save the repaired file separately from the original and state which file should be published.

Escalate when repair is unsafe or ambiguous

Use a specialist for complex tables, mathematical notation, charts whose meaning is not captured by a short description, forms with conditional logic, damaged character encoding, or a document where the source and record requirements conflict. Include the original and working copy, a page-by-page defect log, and the user task. If a reliable repair cannot be completed before publication, provide the clearest accessible alternative available and record the limitation for follow-up; do not describe the PDF as fully conforming.

Give the file a clear map

In Excel, make the first row of each data table a real header row, keep one value per cell, and avoid merged cells, blank spacer rows, and color-only categories. Give each worksheet a descriptive name and put a short instruction or summary at the top when the purpose is not obvious. Keep number formats, dates, units, and formulas consistent so a reader can understand the data without guessing.

In PowerPoint, start with a built-in slide layout. Give every slide a unique title, use short text blocks, and keep the visual hierarchy consistent. A slide that looks orderly can still read in the wrong order if objects were copied, layered, or rearranged. Treat notes, embedded media, and charts as content that needs an access plan, not as decoration.

Make data and charts understandable

Label the meaning behind a chart in text, not only by color, position, or a legend that is difficult to follow. Add a concise alt text summary for a chart or image and put the important conclusion in nearby text. For a large data story, provide the source table or a short written analysis. In Excel, use accessible contrast and do not rely on red and green alone for status; add words such as “On track” and “Needs attention.”

In PowerPoint, open the Reading Order pane and read each slide's objects from top to bottom in the intended order. Group a complex diagram when a single description is clearer than dozens of shapes. Exclude decorative objects from the reading order. If a presentation contains audio or video, add captions and provide the media alternatives described in the video and audio guide.

Check the task, not just the file

1. Run the Microsoft Accessibility Checker in Excel or PowerPoint and fix issues at their source.
2. In Excel, navigate sheets, headers, tables, formulas, filters, and chart alternatives with the keyboard; check zoom and high-contrast viewing.
3. In PowerPoint, review slide titles and reading order, tab through objects, and confirm that hidden or decorative objects are not announced.
4. Export a representative PDF only after the source is correct, then inspect the PDF's tags, reading order, and media links separately.

Checker results are useful prompts, not proof of WCAG 2.2 AA conformance. A human must decide whether the data is complete, the sequence is understandable, and the chart or slide can be used without sight, color, or a mouse.

Hand off dense data and slide design

Ask for specialist review when a workbook has multiple header levels, merged reporting views, pivot tables, macros, conditional formats that carry business meaning, or charts that require a long description. Escalate a deck with complex diagrams, animation that changes meaning, embedded dashboards, or a custom template that changes the reading order. Send the source file, the intended audience, and the key decisions a reader must be able to make.

Identify the media alternatives

First identify whether the file is synchronized video with audio, audio-only, or video-only, and whether it is prerecorded or live. For prerecorded synchronized video with audio, WCAG 2.2 Level A requires synchronized captions and either audio description or a media alternative for the video. Level AA adds the audio-description requirement. For prerecorded audio-only, provide an equivalent transcript; a caption track is not required for standalone audio. For prerecorded video-only, provide a text alternative or an audio track that conveys the information. Live audio in synchronized media requires captions at Level AA.

These are different deliverables. Captions represent speech and meaningful sounds in time with synchronized video. A transcript is a complete, readable text alternative and should include speaker changes and relevant sound or visual information. Audio description voices important visual information during natural pauses. A transcript alone is not automatically an audio description, and captions do not describe visual-only actions.

Produce captions, transcript, and description

Start with a script or clean transcript, then synchronize captions and identify speakers when that helps. Include meaningful sounds such as a warning alarm, a door closing, or music that changes the meaning. Review names, acronyms, numbers, locations, and technical terms. Keep the transcript as HTML when possible so it can be searched, copied, resized, and read by assistive technology.

For a safety demonstration, describe actions a viewer cannot see, such as “The supervisor points to the red shutoff lever on the left side of the panel.” If the narration already conveys all important visual information, a separate audio-description track is not needed. An accompanying transcript is recommended for usability, but is not a blanket AA requirement for every narrated video. A sign-language version may be useful for the audience; it is not part of the AA target.

Publish with an accessible player

Use a player whose controls can be reached and operated by keyboard, whose captions can be turned on, and whose focus remains visible. Put the title, duration, language, captions, transcript, and any alternative version near the player. A YouTube, Vimeo, or other hosted video still needs an accessible page around it; an embed does not transfer responsibility for the surrounding heading, link, transcript, or instructions.

YouTube can generate captions for video, but its own guidance says automatic captions may misrepresent speech because of accents, pronunciation, dialects, or background noise. Review and edit them in YouTube Studio before treating them as published captions. For synchronized video, check captions at normal speed, with sound muted, and with the transcript open. For audio-only, verify the transcript against the recording instead of assuming a caption track is needed. Also test a direct download or alternate version if the player cannot expose a required feature.

Hand off production and review

Bring in a captioning or media-accessibility specialist when speech overlaps, the edit has little narration over important visuals, the content is live, or a safety or instructional video depends on precise timing. Give the specialist the final cut, script, glossary, speaker names, transcript, intended platform, and a list of visual events that must be described. Keep caption and transcript files with the source so a replacement YouTube or Vimeo upload does not lose them.

Record the media type, language, caption and description status, player tested, date tested, and unresolved issues. A checker cannot judge whether a caption is accurate or whether a visual description preserves the task, so include a human playback review.

Inventory the whole user journey

List every external service in the page or document workflow: a YouTube or Vimeo player, registration form, project gallery, map, document portal, payment step, chat widget, or analytics-driven component. Record the provider, URL, embed or link method, data collected, owner, and the task it supports. A page can be visually simple while its most important action is trapped inside an inaccessible iframe.

Test the experience as a visitor who is keyboard-only, zoomed in, using a screen reader, or using captions. Check headings, labels, focus order, error messages, contrast, language, time limits, downloads, mobile layout, and whether the service works without a mouse. Review the provider's accessibility statement or VPAT as evidence to investigate, not as a substitute for testing the configured experience.

Choose and integrate with an equivalent path

Before procurement or renewal, ask whether the provider supports keyboard operation, accessible names and roles, captions and transcripts, zoom and reflow, accessible form errors, and a documented issue process. Keep the required information in your own page when practical. For example, introduce a registration form with an HTML heading and instructions, then provide a plain link to the vendor form and a downloadable accessible alternative if the embed fails.

Label an iframe with a meaningful title, give the external link descriptive text, and do not place an essential notice only inside a player or widget. An accessible alternative must provide the same information or task, not merely a screenshot or a sentence telling people to call someone. Keep the alternate path current when the vendor changes its URL or workflow.

Monitor and escalate changes

Set a review cadence based on risk and change frequency. Recheck the first task after a provider release, embed-code update, or new content upload. Record the URL, date, browser and assistive technology used, result, and issue reference. If an uncontrolled service introduces a barrier, make the equivalent path prominent while the provider investigates. Remove, replace, or isolate a component that blocks a core task.

WCAG 2.2 describes a statement of partial conformance for uncontrolled third-party content, but that statement acknowledges non-conformance and does not turn inaccessible content into an exemption. Do not publish a broad claim that the site is conformant while a known vendor barrier remains in a covered user journey. Describe the tested scope and limitations accurately.

Hand off provider issues with a reproducible case

Send the vendor a short reproduction: page or embed URL, exact task, keyboard steps, focus or announcement observed, browser and assistive technology, date, and a recording or screenshot only when it does not expose personal information. Include the accessibility requirement or WCAG success criterion that explains the barrier. Keep the page owner, procurement contact, and content editor aligned on the workaround and next review date.

Design the library around tasks

Organize by the questions visitors ask: find a current report, complete a form, read a meeting packet, review a design standard, or watch a safety video. Use page headings and short summaries before the download list. For simple information, publish an HTML page first and offer a document for printing or record use. A PDF is not automatically a better format than HTML, and a scan should never be the only copy of essential text.

Give each item a stable title, content type, date or version, language, and short description. Use a filename that remains meaningful after download, such as 2026-design-standards.pdf, rather than a system-generated string. Mark a replacement or archive clearly so a visitor does not have to compare several files to find the current version. For operational forms, expose the form ID and revision in the page heading or summary, not only inside the file.

Write useful download links

Make the link text identify the document and format. Include size when it affects a person's decision to download. “2026 design standards, accessible PDF, 2.4 MB” gives more information than “Download” or “PDF.” Do not repeat the same generic link label ten times in a list. Put the file format in text, not only in a colored icon, and do not make an image the only link.

Keep the page heading, link label, file title, and document title consistent. If a file is a form, say whether it is fillable and whether an HTML or Word alternative is available. If a media item is hosted on YouTube, Vimeo, or another portal, describe the media and link to its transcript or alternative near the player. For an external portal, add a short warning that the visitor is leaving the site only when that information helps the task.

Track form IDs, revisions, and status

For every reusable form or checklist, maintain a small record with the form ID, exact title, revision or effective date, owner, source file location, published URL, file type, language, and current status. If the file has a revision printed in its footer, make the landing page match it. If the owner cannot confirm the revision, mark the item for review instead of guessing that the newest upload is current.

1. Choose one primary landing-page link and identify the current edition in its label.
2. When replacing a file, update the title, revision, size, language, format, and accessibility-review date together.
3. Check the old direct URL, search result, saved bookmark, and any page that linked to the old file. If the URL changed, ask the website team to update links or arrange an appropriate redirect. Download the published copy while signed out to check that a cached older file is not being served.
4. Move superseded editions out of current-task lists. Label any public retained edition Archived - not for current submissions, and follow the responsible owner's retention process. Do not delete records as part of routine file replacement.

Do not silently overwrite a signed or record copy. Preserve the original and publish an accessible working copy only when the responsible owner has defined how the copies relate. Continue with the fillable PDF form guide when the item includes fields, required states, or submission instructions.

Inventory and maintain every item

1. Keep a content inventory with the public URL, file URL, owner, type, language, publication date, review date, source file, form or document ID, revision, current or archived status, and accessibility status.
2. Prioritize forms and deadline-driven documents, then reports, standards, meeting materials, project galleries, and media that receive frequent visits.
3. At each review, open the actual download, check that the title and language are present, run the applicable checker, and manually test the task.
4. When replacing a file, keep the landing page and link stable where possible, remove duplicate or obsolete links, and check that old bookmarks do not lead to a missing file.

Do not label an item “accessible” solely because Word, Excel, PowerPoint, YouTube, or Acrobat reported no automated errors. Record what was tested, by whom, with which tool and date, and what remains uncertain. Continue with the PDF guide or media guide for format-specific checks.

Hand off library gaps

Escalate a library item when its owner is unknown, the source is missing, a current form cannot be completed by keyboard, a scanned record needs OCR and structural repair, a media file lacks captions or description, or a third-party portal is the only route to a core task. Send the public URL, file, source if available, inventory metadata, user task, test evidence, and a proposed alternative. Keep the item visible only with an accurate note about its current format or limitation; do not promise compliance or a repair date until the responsible team confirms it.

Use a review step before every release

This is a proposed BuildLACCD publishing procedure. The District should approve the process and assign the roles before treating it as an operating policy. Small text edits still need a quick check; a new form or document needs a fuller review.

Keep the request, source files, review results and release note together in the team’s approved tracking system. A completed checklist is useful evidence of work performed, not proof of WCAG conformance.

Prepare the content and the request

1. Identify the destination. Record the page URL, purpose, content owner and requested publication date. List every document, image, form or embedded service being added.
2. Choose the right format. Put event details, instructions and short announcements on the web page. Use a downloadable file when the document format serves a real purpose.
3. Supply accessible source material. Include the editable document, checked PDF if needed, meaningful link labels, image descriptions and reviewed captions. Do not leave these decisions until upload day.
4. State the review scope. A revised report needs document checks and a download-link check. A form replacement needs a complete submission test, including errors and confirmation.

Review the preview, then approve it

Use a draft or staging preview before changing the public page. The editor completes the relevant guide’s checklist. A second person checks the changed content in its page context. Include keyboard use, zoom and a small-screen view; use specialist testing for complex documents or interactive components.

If a visitor cannot read the information or complete the task, pause the affected update and assign the fix. Escalate urgent notices to the designated owner for an accessible publication plan. An inaccessible attachment plus a contact line is not an automatic exception.

The reviewer records either “ready to publish” for the stated scope or “changes required,” with the remaining issues. Technical changes to templates, plugins or forms go to the website team for testing and a recovery plan.

Publish and check the actual result

1. Publish the approved version. Record the live URL, date, editor, reviewer and a short description of the change.
2. Open the public page while signed out. Confirm that the correct file downloads, the image description is present in the rendered page, and links and controls work.
3. Recheck the changed task. Clear a stale cache through the website team if the old version is still visible.
4. Attach the live check results to the release record. If a problem appears, log it and correct or safely roll back the affected change.

Decisions to make before adoption

The assignments below are a proposed operating model, not an approved District policy or a statement about existing staff duties. Program leadership should name the responsible people, their backups and an escalation contact. One person may fill more than one role, but higher-risk work should still receive a separate review.

• Approve WCAG 2.2 Level AA as the website’s technical target and define the scope, including documents, media and third-party user journeys.
• Identify the policy approver and the person accountable for maintaining this guide.
• Set response and remediation timeframes based on impact, urgency and available resources.
• Confirm a monitored way to report barriers and request assistance.
• Approve the review schedule, record-retention rules and staff training plan.

Any legal determination about obligations or exceptions belongs with the District’s authorized policy and legal personnel.

Assign these responsibilities

Make the handoff specific

A request that says “make this accessible” leaves too much open. Send the page or file, the intended task, the problem encountered and any deadline. Identify which parts have already been checked and which need specialist review.

Do not ask editors to add unfamiliar ARIA attributes or patch theme code. Equally, do not assume a developer can invent the correct description of a project photograph or validate the facts in a financial report.

Give each role the right training

New editors should practice on a draft page containing a heading, image, document link and event notice. Document authors should practice exporting and checking a report. Reviewers need a repeatable keyboard and zoom test. The website team needs component-level and assistive-technology testing skills.

Keep approved templates and example files in a shared location. Revisit training when the editor interface changes, a recurring issue appears or a new content type is introduced.

Adopt a practical review schedule

The schedule below is a recommendation for BuildLACCD to approve and resource. These intervals are not WCAG requirements. Increase review frequency for deadline-sensitive notices, frequently changing content or repeated failures.

Treat plugin and template updates as releases

Before changing Elementor templates, a gallery, Gravity Forms or another shared component, identify the pages and tasks it affects. Use a staging environment and preserve a recoverable version. Test the component with representative content and interaction states.

• Check menus, keyboard focus, mobile reflow and any sticky content.
• For forms, test required fields, invalid input, correction and successful submission in an approved test environment.
• For galleries and media, test every control and the way focus enters and leaves the viewer.
• Run automated checks, investigate flagged items and record manual test results.

Repeat the relevant checks after deployment. A staging pass does not establish that the production configuration, cached page or embedded service works the same way.

Keep evidence that can be compared

Save the date, environment, page URLs, file versions, test method and scope. For automated scans, retain the tool and version, ruleset, raw output and any exclusions. For manual tests, record the browser, assistive technology where used, steps and observed result.

Track each confirmed issue from discovery through assignment, repair and retest. Report open barriers and affected user tasks, not only a score or percentage. A decrease in scan findings can reflect a smaller sample rather than a better website.

Use analytics to help prioritize heavily used pages, but do not exclude low-traffic content that supports important services. Review feedback and accommodation requests as additional evidence.

Maintain the guide as well as the website

Assign an owner to review this guide when WCAG guidance, authoring tools or site components change. Keep a short revision history describing substantive changes. Replace obsolete screenshots and verify source links. Record the next scheduled review in the team’s tracker.

Check the public accessibility statement against actual evidence. It should describe the scope, known limitations and a usable feedback route without claiming that a clean automated scan proves complete conformance.

Start with the person’s task

If someone cannot use a page, document or form, ask what they are trying to do and which format or contact method would help. Do not require a diagnosis, medical information or a screenshot before offering assistance. A report in plain language is enough to begin.

The District should designate the monitored intake channel, responsible staff and response timeframes. Until those are approved, do not publish invented commitments or an unmonitored accessibility email address. For current contact options, use the BuildLACCD contact page; staff should route the request to the appropriate owner.

Create an actionable issue record

• Location: page URL, document title and version, or the embedded service.
• Task and barrier: what the person was trying to do and what prevented it.
• Reproduction: steps and relevant browser or assistive technology, if known. Do not make technical details a condition of help.
• Impact and urgency: affected service, deadlines and whether an alternative route works.
• Ownership: assigned person, next action, target date and current status.
• Evidence: test results, repair details, retest result and closure date.

Keep personal contact details in the approved private system, separate from public release notes. Record only what is needed to resolve the request and follow the District’s retention rules.

Prioritize by user impact

A form that cannot be submitted or a notice that cannot be read may block an essential task. Escalate those barriers promptly, especially when a deadline is approaching. A confusing link or image description still needs attention, even if an automated tool does not flag it.

Assign a correction owner and a realistic target date. If a third-party service is involved, keep a BuildLACCD owner on the issue while working with the supplier. Do not close the record simply because a vendor ticket was opened.

Provide assistance while the repair is underway

Depending on the need, provide an accessible HTML version, a checked document, a corrected transcript or staff assistance through a method the person can use. Preserve the same essential information and opportunity to participate. Confirm that the alternative actually works for the requester.

Alternative assistance does not by itself make the inaccessible page conform to WCAG. Nor does an internal risk acceptance waive accessibility obligations. Any formal exception needs review by the District’s authorized decision-maker, with the rationale, affected content, available alternative, owner and review date documented. Editors should not decide that older files are automatically exempt.

Retest before closing

Repeat the original task after the fix. Check the affected page or final file, not only the source. Record the result and, where appropriate, let the requester know what changed and how to obtain further help. Keep unresolved limitations visible to the responsible team.

Choose a real task to test

Open the page preview and decide what a visitor needs to do: read an event notice, open a report, move through a gallery or register. Check the final public version again after publication. These checks find common barriers; they are not a complete conformance audit.

Record the URL, date, browser, viewport and result. If a step fails, describe what happened and send it to the responsible editor or website team. Do not simply mark the entire page “inaccessible” without identifying the blocked task.

Put the mouse aside

1. Reload the page. Press Tab to move forward and Shift+Tab to move back. Every interactive control should be reachable in a sensible order.
2. Look for a visible focus indicator. Make sure cookie notices, sticky headers or floating controls do not completely hide the focused item.
3. Use Enter for links and Enter or Space for buttons. Menus and other complex controls may also use arrow keys.
4. Open and close any menu or gallery viewer. Escape should close a dialog where that behavior is supported; focus should return to a sensible place.
5. Complete the intended task without getting trapped. Test errors and confirmation for a form in an approved test environment.

Some browsers, especially on macOS, have keyboard-navigation settings that affect which controls receive Tab focus. Confirm those settings before interpreting skipped controls as a site defect.

Increase text size and narrow the page

Check browser zoom at 200% for clipped text, overlap and lost controls. For reflow, test a viewport 320 CSS pixels wide, or start with a 1280-CSS-pixel-wide viewport and zoom to 400%. Ordinary paragraphs should not require scrolling both horizontally and vertically. Content that genuinely needs two-dimensional layout, such as a data table, has specific exceptions.

Try the page on a small screen too. Confirm that links are comfortable to activate and that orientation is not unnecessarily restricted. A narrow-screen test is useful, but does not replace zoom and text-resize checks.

Review meaning as well as appearance

Read the headings as an outline. Check that link labels identify their purpose and that essential event information is outside the flyer image. Ask whether an image description supplies the information its context requires. For video, review captions for accuracy and determine whether important visual information needs audio description.

Check text and control contrast using a measurement tool. Normal text generally needs 4.5:1; large text has a 3:1 threshold. The example tools include a solid-color contrast check. Image backgrounds, hover states and gradients need additional inspection.

Add trained and automated testing

A trained reviewer should check headings, landmarks, links, form labels and status announcements with a screen reader, then complete the main task. Record the browser and screen-reader combination. Merely hearing the page read aloud does not establish that its structure and controls are accessible.

Run an automated scanner on the same page and interactive states. Confirm each finding, investigate items needing manual review, and retain the results. Automated tools cannot reliably judge the quality of every description, caption, reading order or interaction. Combine their output with manual testing and, where practical, feedback from people with disabilities.

AA includes both A and AA requirements

WCAG is the Web Content Accessibility Guidelines, published by W3C. This guide uses version 2.2, Level AA as its technical target. Level AA conformance requires meeting all applicable Level A and AA success criteria, including those that require human evaluation.

The target applies to complete pages and complete processes. A usable event page does not make its registration journey accessible if the next step cannot be completed. Third-party content and downloadable documents need attention too.

The articles translate common publishing tasks into practical steps. They do not replace the full standard, a scoped accessibility evaluation or the District’s policy decisions.

What 2.2 adds to the team’s checks

WCAG 2.2 adds six A or AA success criteria to the 2.1 requirements. These affect components as well as editorial choices:

• Focus not obscured (2.4.11, AA): author-created content must not completely hide a component when it receives keyboard focus.
• Dragging movements (2.5.7, AA): provide a single-pointer method that does not require dragging, unless an exception applies.
• Target size (2.5.8, AA): pointer targets generally need to be at least 24 by 24 CSS pixels, or meet an exception such as sufficient spacing. Inline text links have an exception. This guide recommends larger, 44-pixel controls where practical.
• Consistent help (3.2.6, A): repeated help mechanisms should appear in a consistent relative order.
• Redundant entry (3.3.7, A): do not make people enter the same information again in the same process when it can be supplied or selected, subject to the criterion’s exceptions.
• Accessible authentication (3.3.8, AA): avoid cognitive-function tests such as memorizing or transcribing information unless an allowed alternative, assistance mechanism or exception applies.

The old Parsing criterion, 4.1.1, is removed in 2.2. Invalid markup can still cause failures under other criteria. The three new AAA criteria are not part of an AA target.

Separate requirements from working preferences

WCAG sets testable outcomes. The way the team achieves them can vary. Descriptive headings and usable keyboard controls address accessibility requirements. A second-person review, monthly link check or preferred file-naming pattern is a recommended procedure that helps maintain those outcomes.

Each article lists relevant WCAG criteria where useful. The list is a cross-reference, not a complete checklist or a certification for that content type. Document accessibility also needs format-specific checks; a PDF/UA check and a WCAG evaluation do not establish identical things.

Be precise about what has been verified

Use statements such as “the listed pages were tested on this date with these methods” rather than “100% accessible.” Preserve the test scope, results, limitations and outstanding issues. Do not treat this guide, an accessibility widget or a clean automated scan as evidence that the whole website conforms.

Before publishing a conformance claim, obtain a documented evaluation covering the claimed scope and have the statement reviewed by the responsible District owner.