Architecture Demos
Choose a capability, run one focused demonstration, and inspect what happened.
Accessibility
Operate accessible behavior and inspect bounded failure analysis.
Accessibility is behavior.
Operate the accessible example, then compare each behavior with an inert failure fixture and an honest verification boundary.
Accessible behavior
Operate the working interaction
How to run
- Press Tab through the sample controls and check the visible focus indicator.
- Open Sign in options, press Tab inside the dialog, then press Escape to return focus.
- Reorder the task with Move up and Move down.
- Press Run automated check to start axe and read the announced result.
axe-core / partial coverage
Automated check of accessible behavior
axe checks only the live accessible interaction above. The failure fixtures below are inert teaching material and are not represented as passing automated tests.
- Critical
- 0
- Serious
- 0
- Moderate
- 0
- Minor
- 0
Waiting for the isolated accessible frame.
- No scan result yet.
Failure analysis
12 criteria · WCAG 2.2 + APGEach fixture is escaped code, not a live broken control. Verification combines automation with the manual checks that automation cannot perform.
| Criterion | Working behavior | Failure fixture | How we verify it |
|---|---|---|---|
| 2.1.1 · 2.4.3Keyboard navigation | Use Tab and Shift+Tab through native controls in a logical order. | A pointer-only control excludes keyboard operation. | Keyboard walkthrough plus semantic-control inspection. |
| 2.4.7 · 2.4.13Focus visibility | Every control displays the shared three-pixel focus indicator. | Removing the outline hides the current keyboard position. | Manual keyboard check; CSS inspection supports but cannot replace it. |
| 2.4.11Focus not obscured | Focused content remains clear of the persistent footer. | A fixed overlay can cover the focused control. | Manual focus traversal at representative viewport sizes. |
| APG dialog · 2.4.3Modal behavior | Open Sign in options, use Tab and Escape, and confirm focus returns. | An unlabeled overlay has no modal semantics or focus management. | Keyboard interaction plus role, name, and aria-modal inspection. |
| 1.1.1Image alternative | The deployment illustration has a concise bounded alternative. | Omitting alt leaves the image without a programmatic alternative. | DOM inspection plus judgment that the alternative fits the context. |
| 1.3.1 · 3.3.2Landmarks and labels | Regions are semantic and every input has an associated label. | Generic containers and placeholder-only inputs lose structure. | Automated name/role checks plus screen-reader structure review. |
| 2.5.5 · 2.5.8Target size | Interactive targets meet the shared 44 by 44 CSS-pixel baseline. | Adjacent undersized buttons are difficult to operate accurately. | Computed-size inspection at desktop and mobile widths. |
| 1.4.3 · 1.4.6 · 1.4.11Contrast | Text and non-text states use the tested light and dark palette. | A low-contrast foreground can make instructions unreadable. | Contrast calculation plus manual inspection of non-text states. |
| 3.3.7Redundant entry | The previously supplied email remains populated. | Requiring the same information again creates avoidable work. | Complete the flow and confirm previously entered data persists. |
| 3.3.8 · 3.3.9Accessible authentication | Paste, password managers, saved passwords, and passkeys remain available. | Paste blocking or a cognitive puzzle can prevent authentication. | Manual paste/password-manager check; automation cannot prove usability. |
| 2.5.7Dragging alternatives | Move up and Move down buttons accompany the draggable task. | A drag-only interaction has no single-pointer alternative. | Operate the equivalent action without a dragging gesture. |
| 3.2.6Consistent help | Account help remains in the same predictable location. | Removing or moving help between steps makes it harder to find. | Manual comparison across the representative workflow. |
2.1.1 · 2.4.3Keyboard navigation
Working behavior
Use Tab and Shift+Tab through native controls in a logical order.
Failure fixture
A pointer-only control excludes keyboard operation.
<div onclick="submitRelease()">Submit</div>How we verify it
Keyboard walkthrough plus semantic-control inspection.
2.4.7 · 2.4.13Focus visibility
Working behavior
Every control displays the shared three-pixel focus indicator.
Failure fixture
Removing the outline hides the current keyboard position.
*:focus { outline: none !important; }How we verify it
Manual keyboard check; CSS inspection supports but cannot replace it.
2.4.11Focus not obscured
Working behavior
Focused content remains clear of the persistent footer.
Failure fixture
A fixed overlay can cover the focused control.
footer { position: fixed; bottom: 0; }
/* no content clearance */How we verify it
Manual focus traversal at representative viewport sizes.
APG dialog · 2.4.3Modal behavior
Working behavior
Open Sign in options, use Tab and Escape, and confirm focus returns.
Failure fixture
An unlabeled overlay has no modal semantics or focus management.
<div class="overlay"><h2>Options</h2>...</div>How we verify it
Keyboard interaction plus role, name, and aria-modal inspection.
1.1.1Image alternative
Working behavior
The deployment illustration has a concise bounded alternative.
Failure fixture
Omitting alt leaves the image without a programmatic alternative.
<img src="deployment-tiles.svg">How we verify it
DOM inspection plus judgment that the alternative fits the context.
1.3.1 · 3.3.2Landmarks and labels
Working behavior
Regions are semantic and every input has an associated label.
Failure fixture
Generic containers and placeholder-only inputs lose structure.
<div class="main"><input placeholder="Email"></div>How we verify it
Automated name/role checks plus screen-reader structure review.
2.5.5 · 2.5.8Target size
Working behavior
Interactive targets meet the shared 44 by 44 CSS-pixel baseline.
Failure fixture
Adjacent undersized buttons are difficult to operate accurately.
.tiny button { width: 18px; height: 18px; }How we verify it
Computed-size inspection at desktop and mobile widths.
1.4.3 · 1.4.6 · 1.4.11Contrast
Working behavior
Text and non-text states use the tested light and dark palette.
Failure fixture
A low-contrast foreground can make instructions unreadable.
.hint { color: #aaa; background: #fff; }How we verify it
Contrast calculation plus manual inspection of non-text states.
3.3.7Redundant entry
Working behavior
The previously supplied email remains populated.
Failure fixture
Requiring the same information again creates avoidable work.
<input name="email" value=""> <!-- repeated step -->How we verify it
Complete the flow and confirm previously entered data persists.
3.3.8 · 3.3.9Accessible authentication
Working behavior
Paste, password managers, saved passwords, and passkeys remain available.
Failure fixture
Paste blocking or a cognitive puzzle can prevent authentication.
<input type="password" onpaste="return false">
<p>Solve 9 × 7 to continue.</p>How we verify it
Manual paste/password-manager check; automation cannot prove usability.
2.5.7Dragging alternatives
Working behavior
Move up and Move down buttons accompany the draggable task.
Failure fixture
A drag-only interaction has no single-pointer alternative.
<li draggable="true">Verify health check</li>How we verify it
Operate the equivalent action without a dragging gesture.
3.2.6Consistent help
Working behavior
Account help remains in the same predictable location.
Failure fixture
Removing or moving help between steps makes it harder to find.
<!-- help link omitted from this step -->How we verify it
Manual comparison across the representative workflow.