Project 01 · Website accessibility

Audit, remediation, and verification

A standards-based evaluation of a fictional community learning website, designed to demonstrate how I move from user impact to reproducible defect, code guidance, and retest evidence.

Review findings Open before example Open remediated example

My role: Created the simulation; scoped, tested, documented, remediated, and retested it
Target standard: WCAG 2.2 Level AA · Revised Section 508
Test matrix: Keyboard, screen reader, structure, contrast, zoom, reflow, and code review
Outcome: Eight findings remediated and targeted for retest

Evaluation scope

A repeatable audit process

Scenario: Open Path Learning is a fictional nonprofit experience created for this portfolio. No client or student information is used.

Representative flows: Navigate the site, review classes, follow course links, complete the update form, recover from an error, and confirm success.

Limitations: This focused demonstration is not a full conformance claim. It evaluates selected components and task flows against applicable criteria.

Automated checks support discovery; manual evaluation determines whether the experience works in context.

Audit results

Representative findings

Eight findings with impact and remediation guidance
Severity	Area	WCAG	User impact	Recommendation
Critical	Keyboard access	2.1.1	Mouse-only controls blocked task completion.	Replace custom click targets with native controls and verify keyboard activation. Targeted retest: passed
Serious	Focus visible	2.4.7	Keyboard focus was not visually apparent.	Provide a persistent, high-contrast focus indicator with adequate offset. Targeted retest: passed
Serious	Accessible names	4.1.2	An icon control and email input lacked reliable names.	Use visible labels and confirm the computed name in the accessibility tree. Targeted retest: passed
Serious	Form errors	3.3.1	Errors depended on color and were not announced.	Associate specific error text with the field and move focus when submission fails. Targeted retest: passed
Moderate	Heading structure	1.3.1	Styled text did not expose a logical hierarchy.	Use a meaningful h1–h3 outline that reflects page relationships. Targeted retest: passed
Moderate	Color contrast	1.4.3	Muted text fell below the AA contrast requirement.	Adjust foreground and background tokens and retest each state. Targeted retest: passed
Moderate	Link purpose	2.4.4	Repeated “Learn more” links lacked context.	Name the destination or purpose within each link. Targeted retest: passed
Moderate	Status messages	4.1.3	Success confirmation was not announced.	Expose the update through a polite status region without moving focus. Targeted retest: passed

Technical remediation

The code change—and why it matters

These focused examples demonstrate semantic HTML and purposeful ARIA. Each recommendation begins with the user barrier, uses native HTML where possible, and ends with assistive-technology verification.

Use a native button for an action

WCAG 2.1.1 · 4.1.2

Before

<div class="submit" onclick="send()">→</div>

After

<button type="submit">Subscribe to course updates</button>

Why: The native button supplies role, focusability, an accessible name, and expected Enter/Space behavior without recreating them with ARIA.

Associate instructions and errors with the field

WCAG 3.3.1 · 3.3.2 · 4.1.2

Before

<input placeholder="Email">
<p class="error">Required</p>

After

<label for="email">Email address</label>
<p id="hint">Example: name@example.com</p>
<input id="email" type="email"
  aria-describedby="hint email-error"
  aria-invalid="true">
<p id="email-error">Enter a valid email address.</p>

Why: The visible label creates a stable name. The description and error are programmatically connected, while aria-invalid exposes the current state.

Announce a dynamic result

WCAG 4.1.3

Before

<p class="success">You are subscribed.</p>

After

<p role="status" aria-live="polite">
  You are subscribed.
</p>

Why: A polite status region announces the update without unexpectedly moving keyboard focus. The live region must exist before its text changes.

Give links a purpose in context

WCAG 2.4.4

Before

<a href="/course">Learn more</a>

After

<a href="/course">
  Learn more about Digital essentials
</a>

Why: Specific link text remains understandable when a screen-reader user navigates by links or encounters several similar cards.

ARIA judgment

Native semantics first

ARIA can clarify relationships and dynamic states, but it does not add behavior automatically. I begin with the correct HTML element, add ARIA only when the native language cannot express the necessary relationship, and verify the resulting role, name, state, value, focus order, and interaction.

Prefer <button> to a clickable <div>.
Prefer <label> to an input labeled only through placeholder text.
Do not add redundant roles to native elements unless testing establishes a specific compatibility need.
Test the computed accessibility tree and actual screen-reader output.

Verification

Close findings with evidence

Each original task is repeated after remediation. A finding closes only when the code-level change is present, keyboard behavior is correct, screen-reader output communicates the intended semantics, and the fix has not introduced a regression elsewhere in the flow.

Open sample audit report Review full methodology