Web Accessibility curriculum

Framing it this way changes who the work is for: the same design that serves a permanently blind user serves someone with a broken arm and someone squinting at a phone in sunlight. That reframing is the practical argument, because it moves the audience from a minority to everyone at some point.

Four buckets covering whether content can be sensed, operated, understood and parsed by the tools people use. Their value is diagnostic rather than legal — when something is wrong, naming which bucket it falls into usually identifies the class of fix before any criterion is consulted.

Four standards with four different audiences: content, the semantics available to markup, the tools that produce content, and the tools that consume it. Confusing them is why a question about a browser's behavior gets answered with a content criterion, which cannot resolve it.

Each version adds criteria and changes none, so conforming to a later version at a given level means conforming to every earlier one at that level too. That additivity is what makes a claim comparable across years, and it means an upgrade is new work rather than re-verification.

Three levels where the middle one is what procurement and legislation almost always name, and the highest is explicitly not expected across a whole site. Treating the top level as the aspiration for everything misreads the standard, which says it is not achievable for all content.

A single failure at a level fails the page at that level, with no partial credit and no averaging. That is harsh and it is what makes a conformance claim mean anything — a claim about a mostly-conforming page would be a claim about nothing in particular.

You cannot carve out part of a page from the claim, and a multi-step process conforms only if every step does. That second rule is the one that bites: a checkout with one inaccessible step is an inaccessible checkout regardless of how good the other four are.

A technique only counts if the assistive technology people actually use supports it, which makes conformance partly an empirical question about the ecosystem rather than purely about the markup. It is why a technically correct approach can still fail in practice.

Even content excluded from a conformance claim must not trap the keyboard, play audio unbidden, flash, or prevent pausing. These are the few requirements that apply to everything on the page, which is why a third-party widget cannot be waved away as out of scope.

The criteria are the requirement; the explanatory pages, technique documents and pattern library are guidance and are not binding. That distinction matters in an argument — failing to follow a suggested technique is not a failure, and meeting the criterion another way is legitimate.

The alternative conveys what the image communicates in context, which is usually not a description of the picture — a photograph illustrating an article and the same photograph in a gallery need different text. Writing what is depicted rather than what is meant is the commonest miss.

An explicitly empty value removes the image from the tree entirely, which is what a spacer or a border needs. Omitting the attribute is a different thing: some readers then announce the file name, which is worse than either alternative.

When the image is the control, the alternative names the action rather than the picture — an envelope icon that opens mail is named for contacting, not for the envelope. Describing the artwork leaves the user knowing what it looks like and not what it does.

A chart carries a dataset and a relationship, which no short alternative can hold, so the equivalent has to exist elsewhere on the page as text or a table. Attempting to compress it into the attribute produces something unreadable and still incomplete.

Inline vector markup is not treated as an image by default, so a meaningful one needs an explicit role and a titled child to be named at all, and a decorative one needs hiding. Leaving it unmarked produces either silence or a reading of its internal structure.

Anything painted by stylesheet is absent from the accessibility tree, so meaning carried there reaches nobody using assistive technology. The rule follows directly: if an image conveys information, it belongs in the document, and the stylesheet is for decoration.

Captions include speaker identification and meaningful non-speech sound; subtitles carry dialogue only, usually for translation. The distinction is not pedantry — a door slam or a change of speaker is information the dialogue does not contain, and its absence changes the content.

The two sit at different conformance levels, which is a judgment about difficulty rather than about importance. Knowing which is which decides what a claim at a given level actually obliges, and live captioning is the one most often assumed to be out of scope when it is not.

It narrates visual information the soundtrack never states — an expression, an on-screen caption, an action in silence — which is exactly the material a transcript of the dialogue cannot contain. Producing it means writing to the gaps rather than to the speech.

A transcript is sufficient for audio-only content and never a substitute for captions on video, because reading elsewhere loses the synchronization with what is on screen. Offering one instead is a common and well-intentioned substitution that does not meet the requirement.

Headings are the outline people navigate by, jumping between them rather than reading linearly, so a skipped level reads as a missing section. That is why the level expresses depth and the styling is a separate decision — demoting a heading to make it smaller breaks the map.

Regions expose jump targets that a sighted pointer user never encounters, which makes them navigation infrastructure rather than semantic decoration. A page built entirely from generic containers offers no way to skip anything, which is felt on every single visit.

Header cells with an explicit scope let a reader announce which row and column a value belongs to, and irregular tables need explicit pairing instead. Without either, the table is a grid of numbers with no way to tell what any of them describe.

Document order is the reading order, and layout properties that visually reorder content leave the two disagreeing — so the page reads in one sequence and is spoken in another. The fix is ordering the document correctly and using layout for position, not for sequence.

An instruction relying on shape, color, size or position is unusable by anyone who cannot perceive that characteristic, which includes a screen-reader user and someone with low vision. Naming the thing as well as locating it costs a few words and removes the dependency.

Marking fields that collect information about the user in a machine-readable way lets a browser or assistive tool fill, relabel or re-present them. It is the criterion that makes personalization possible, and it costs one attribute on fields that already exist.

Two thresholds, one for ordinary text and a lower one for large text, on the reasoning that larger glyphs remain legible at lower contrast. They are minimums rather than targets, and designing exactly to them leaves nothing for the conditions real reading happens in.

The threshold is defined by size and weight together, with bold text qualifying at a smaller size. It is worth knowing precisely, because the lower ratio is only available once the text genuinely meets the definition — and a heading one pixel under it does not.

The ratio is computed from linearised luminance rather than from perceived difference, which is why two colors can pass and still look poor, or fail and look fine. Knowing it is a formula rather than a judgment explains both the surprises and why a checker disagrees with an eye.

Control boundaries, focus indicators and meaningful graphics carry their own threshold, which is what catches a beautifully subtle input border that nobody can find. It is the criterion most often missed by design systems built entirely around text contrast.

Disabled controls, pure decoration, logotypes and incidental text are exempt, which is a narrower list than it sounds. In particular a disabled control still has to be findable and understandable — the exemption is about contrast, not about usability.

Color may carry information as long as it is not the only thing carrying it, so an error state needs text, an icon or a shape in addition. The rule is about redundancy rather than about avoiding color, which is the misreading that produces gray, joyless interfaces.

Text must reach double size without losing content or function, which is a test of the layout absorbing larger text rather than of the zoom control existing. Fixed-height containers and clipped overflow are what fail it, and they fail invisibly at default size.

Content must work at a narrow equivalent width without requiring scrolling in two directions, which is what zooming to a high level on a desktop produces. It is effectively the mobile layout requirement arriving through the zoom path, and a desktop-only site fails it.

Content genuinely requiring two-dimensional layout — data tables, maps, diagrams, code — is exempt, which is a real allowance and a frequently abused one. The test is whether the two-dimensional presentation is essential to the meaning rather than merely convenient.

Restricting content to one orientation fails unless that orientation is essential, because a device may be mounted in a fixed position on a wheelchair or a stand. It is one of the clearest cases where a design preference collides with someone's physical setup.

The page must absorb specified increases in line, paragraph, letter and word spacing without losing content, which tests whether containers grow with their text. It exists because people with dyslexia and low vision apply exactly those overrides.

Suppressing pinch zoom removes the single most-used low-vision accommodation on the platform where it matters most. It is one line of markup, usually copied from a template, and it fails a criterion while looking like a layout nicety.

Additional content revealed on hover or focus must be dismissible without moving the pointer, hoverable so it can be read, and persistent until dismissed. Most tooltip implementations fail at least one, usually by vanishing the moment the pointer moves toward them.

Every function, not most of them — which includes drag-and-drop, hover-revealed menus and interactions inside a canvas. The criterion is about the absence of a mouse rather than about the presence of a keyboard, so a mouse-only feature is a barrier however small it seems.

A click handler on a generic element produces something that looks interactive and has no focusability, no key handling, no role and no state. Each of those has to be rebuilt by hand, which is four opportunities to get it wrong compared with using the element that has them.

Focus must always be able to leave a component using standard keys, which is the requirement that embedded media players and custom editors most often break. A trap is the most severe keyboard failure because it ends the session rather than degrading it.

One value inserts an element into the natural sequence and the other makes it focusable only by script. The second is the useful one for managed focus inside a widget, and confusing them either adds noise to the tab order or makes a control unreachable.

Any positive value jumps the element ahead of the entire natural order, so a single one reorders the whole page. It is almost never what the author intended, and the resulting sequence is impossible to reason about once more than one exists.

Native buttons respond to both keys and links only to one, which is a real behavioral difference users rely on. A custom control has to implement whichever set matches the role it claims, and implementing neither is the usual result of building from a generic element.

The native attribute removes the control from the tab order entirely, so a keyboard user never discovers it exists; the ARIA property keeps it discoverable and announced as unavailable. Choosing between them is a question about whether the user should know it is there.

A single-character shortcut collides with speech input and with anyone whose typing lands somewhere unexpected, so it must be switchable off, remappable, or active only when the relevant control has focus. Any one of the three satisfies it.

A time limit must be adjustable, extendable or removable before it expires, which is about giving control rather than about generosity — no fixed limit suits everyone. The exceptions are narrow and mostly cover situations where the timing is essential to the activity.

Anything moving, blinking or updating itself beyond a few seconds needs a control to stop it, because motion in peripheral vision makes reading impossible for some people. It applies to carousels and auto-refreshing content, both of which usually ship without one.

Flashing beyond a low rate can induce seizures, so the limit is a safety requirement rather than a comfort one. It is the criterion whose failure can cause immediate physical harm, which is why it applies to the whole page under the non-interference rule.

Motion triggered by the user's own action — a parallax scroll, a large transition — can cause nausea and disorientation, so non-essential instances need a way to turn them off. The trigger being the user's own scroll is what distinguishes it from the auto-motion criterion.

The operating system already carries the user's answer, so honoring the query respects a preference they have set once rather than asking again per site. Implementing a custom toggle instead means every site asks, which is the outcome the platform setting exists to avoid.

A bypass mechanism spares keyboard users tabbing through the same navigation on every page, and the common implementation only works if it becomes visible when focused. A permanently hidden skip link passes an automated check and helps nobody.

The title is announced first on load and is what distinguishes tabs and history entries, so it needs to be unique and to lead with the distinguishing words. A site name in front of every title makes every entry look identical in exactly the places people scan.

The sequence must preserve meaning and operability, not merely be non-random — so a modal whose focus order wanders back into the page behind it fails even though every element is reachable. Order is part of the content's structure rather than a side effect of the markup.

A link must be understandable from its text and its immediate context, which fails when the context is stripped away — as it is in a list of every link on the page, one of the standard navigation methods. That is why repeated generic link text is a real failure and not a style preference.

Removing the focus ring and putting nothing back is the most common shipped failure in this area, and it is usually done for appearance on a page nobody tested with a keyboard. Replacing it with a designed indicator is entirely legitimate; removing it is not.

The pseudo-class lets the browser decide when an indicator is warranted, showing it for keyboard interaction and suppressing it after a pointer click. It resolves the tension that caused people to remove focus styling in the first place.

A sticky header, a cookie banner or a floating widget can completely hide the element that just received focus, so the user is typing into something invisible. It is a newer criterion precisely because the pattern that causes it became common.

More than one route to each page — search, a site map, or navigation — unless the page is a step within a process. The exception matters: a checkout step is deliberately reached one way, and requiring alternatives there would be wrong.

Any path-based or multipoint gesture needs a single-pointer alternative, because tremor, limited range of motion and head-pointer input all make complex gestures impractical. The alternative is usually a button that already exists somewhere in the interface.

Activating on the release rather than the press means a mis-aimed press can be dragged away and abandoned, which matters for anyone whose pointing is imprecise. It is one line of behavior that turns an irreversible mistake into a recoverable one.

Speech input works by matching what the user says against what is rendered, so a control whose programmatic name reads differently from its printed words matches no spoken command at all. An overriding label that paraphrases the button therefore breaks an entire input method rather than degrading it, which is why the visible words have to survive into the name.

A minimum target size, with spacing counting as an equivalent, addresses the same population as the gesture criteria — anyone who cannot point precisely. Dense toolbars of small icon buttons are the usual failure, and spacing is often the cheaper remedy than resizing.

Inline links within a sentence, controls styled by the browser itself, and targets whose size is essential or duplicated elsewhere are exempt. The inline exception is the broad one, and it is why prose links are not the thing this criterion is aimed at.

Anything achieved by dragging needs an alternative that does not require it — tap to pick up and tap to place, or a menu action. Reordering lists and sliders are the common cases, and both have well-established non-dragging equivalents.

A function triggered by shaking or tilting the device needs a conventional control as well, and a way to turn the motion trigger off. It exists because a device may be mounted, and because involuntary movement would otherwise trigger actions constantly.

Declaring the document's language selects the pronunciation rules a screen reader uses, so an unmarked or wrongly marked page is read with the wrong phonetics throughout — which can be unintelligible rather than merely accented. It is one attribute with a whole-document effect.

Marking a passage in another language stops it being spoken with the surrounding language's phonetics, which matters for quotations, titles and technical terms. It applies to passages rather than to individual borrowed words that have entered the main language.

The value must be a valid standard tag, so a plausible-looking full language name silently does nothing — there is no error and no fallback, just the wrong voice. It is a case where an invalid value and a missing one behave identically.

A new window, a new page, a changed viewport or a moved focus all count, which makes the term broader than it sounds. The criteria that follow all turn on this definition, so knowing what qualifies is what makes them applicable rather than abstract.

Merely receiving focus must not open a dialog, navigate or otherwise change context, because a keyboard user moves focus through everything while exploring. A control that acts on focus makes exploration impossible — every visit is also an activation.

Changing a setting must not automatically submit or navigate unless the user was told beforehand, since someone arrowing through options would trigger it on each one. The advance warning is what makes the pattern acceptable where it is genuinely wanted.

Repeated navigation keeps the same relative order across pages, and the same function keeps the same name. Both reduce the cost of relearning on every page, which is largest for people navigating by memory or by voice.

Where help mechanisms exist, they appear in the same relative place on each page that offers them — so someone who needs help does not have to search for it differently every time. It does not require offering help, only consistency where it exists.

A properly associated label supplies the accessible name and enlarges the click target to include the text, which helps everyone with imprecise pointing. Both benefits come from the same markup, which is why a styled text node beside an input is strictly worse.

It disappears as soon as the user types, usually fails contrast, and is treated as a last-resort source of the name — so a field labeled only by placeholder is unlabeled the moment it has content. It is the most common labeling failure in modern designs.

The error must be described in text, which means a red border or an icon alone conveys nothing to someone who cannot perceive it. The text also has to say what is wrong rather than that something is, which is the difference between a message and a marker.

Where the correction is known, offering it is required — a date format, an allowed range, the field it must match. The exception for security cases is narrow and is not a general license to withhold guidance on ordinary validation.

The pairing is what makes a reader announce the error together with the field rather than leaving the message stranded elsewhere in the document. Marking validity without the association produces a field announced as invalid with no indication of why.

Submissions with legal or financial consequence must be reversible, checked, or confirmed before finalizing, which is a requirement about consequence rather than about complexity. A one-click irreversible purchase is the shape it addresses.

Information already supplied in the same process must not be demanded again, which removes a real burden for anyone with memory or motor difficulties. Auto-population or a selectable copy both satisfy it, and neither is difficult once the data is already held.

An authentication step must not rely on remembering, transcribing or solving something cognitive with no alternative — which is why blocking paste into a password field fails it. Password managers are the accommodation, and preventing them is the barrier.

Every component must expose what it is, what it is called and what state it is in, through the platform interface rather than visually. That triple is the entire contract with assistive technology, and a component missing any part of it is incomplete regardless of appearance.

A control that only looks selected — by color, weight or an underline — communicates nothing about its state, because the visual treatment is not exposed. It is the failure that survives visual review most easily, since the interface plainly shows what is selected.

The parsing criterion is obsolete in the current version, so duplicate identifiers and malformed nesting are now argued under the criteria they actually break. It is one of the few places where the standard removed a requirement, and advice predating that is still widely repeated.

A result count, a save confirmation or a validation summary must reach assistive technology without moving focus, because moving focus interrupts what the user was doing. It is the criterion that live regions exist to satisfy.

It is a pruned projection of the document exposed through a platform interface, so what assistive technology receives is not the markup but a derived structure. That indirection explains why hidden elements vanish from it, why some attributes have no effect, and why inspecting it settles arguments.

Three kinds of information with three lifetimes: what a thing is, what is true of it right now, and what is true of it generally. Knowing which category an attribute belongs to predicts whether it needs updating as the user interacts — states do, properties mostly do not.

Every element already carries a role, so adding one that matches is redundant and adding one that conflicts is a lie. The practical consequence is that most correct markup needs no role attribute at all, which is the opposite of how ARIA is often introduced.

It rewrites what a thing is announced as and changes nothing about how it behaves — no focusability, no key handling, no styling. That is the single most consequential fact about it: giving an element a button role promises behavior that you then have to write entirely by hand.

Prefer the native element, do not override semantics without reason, keep it keyboard operable, never hide a focusable element, and name every control. They are ordered, and the first one resolves most situations before the others become relevant.

A wrong role actively misinforms — it tells the user something untrue and they act on it — while missing markup degrades to whatever the underlying element offers. That asymmetry is why removing incorrect attributes is frequently an improvement on its own.

Several roles are only meaningful inside a specific parent, so an option outside a listbox or a list item outside a list loses the relationship entirely. Building a widget by applying roles to a convenient DOM structure is how this breaks silently.

The role that strips semantics is ignored on a focusable element or on one carrying global ARIA attributes, because removing semantics from something that must be announced would be contradictory. It is a case where the attribute is present and quietly does nothing.

It replaces the visible text in the accessible name, which means the name and what is on screen can diverge — breaking voice control, confusing translation tools, and invisible to anyone reviewing the page visually. Referencing visible text is preferable wherever visible text exists.

Pointing at existing visible text keeps the name and the label from drifting apart, because there is only one string to maintain. It also means a change to the visible text automatically updates the name, which an independent label cannot do.

Supplementary text announced after the name, which users frequently interrupt or skip — so anything essential must not live only there. It is the right place for a hint or an error and the wrong place for the control's actual purpose.

It removes the element and everything inside it from the tree, and it does nothing about focusability — so a hidden element containing a focusable control produces something reachable by tab and announced as nothing. That combination is explicitly forbidden and easy to create.

Three mechanisms hiding from three audiences: everyone, sighted users only, and assistive technology only. Choosing the wrong one either removes content from the people who need it most or leaves visual clutter, and they are frequently used interchangeably by mistake.

It belongs on the control that performs the toggling, because that is what the user interacts with and what needs to announce its state. Putting it on the region being revealed is common and produces a state announced on something the user never focuses.

It is widely written and barely implemented, so it communicates intent to a reader of the source and little to an actual user. Relying on it in place of managing focus produces a widget that is correct on paper and unnavigable in practice.

Three different attributes for three different kinds of toggle, each tied to the role it belongs with. Using the wrong one produces a control announced with a state that does not match its role, which readers may ignore entirely rather than announcing something contradictory.

The name is computed by consulting sources in a fixed order and stopping at the first that yields text, which is why adding a label to an element that already has an overriding attribute changes nothing. Debugging a wrong name means asking which source won, not which sources exist.

Some roles take their name from their text content and others never do, which is why a button needs no label and a text input always does. Assuming adjacent text names a field is the single most common cause of an unlabeled input in an otherwise careful page.

Multiple references join in the order they are listed rather than in document order, which makes the attribute a place where the name is composed deliberately. That ordering is also how a repeated action can be given distinct names by combining a shared verb with a row identifier.

An element may include its own identifier in the list, which is how its own text is combined with another node's rather than replaced by it. It is the mechanism for building a name out of what is already on screen plus a clarifying word.

A referenced node contributes its text even when visually hidden, which makes it a legitimate way to supply a longer name than the design shows. It also means a name can be maintained in a place nobody sees, which is a maintenance hazard as well as a feature.

It never appears on touch, is unreliable on keyboard focus, and loses to every other naming source — so it is a fallback rather than a mechanism. Using it as the primary name produces something that works for a mouse user hovering and for nobody else.

References resolve within a single tree, so an identifier inside a shadow root is unreachable from outside it and vice versa. That constraint shapes how a web component must be named, and it is why a labeling pattern that works in ordinary markup fails inside one.

One queues until the user pauses and the other interrupts immediately, which makes the interrupting variety appropriate only for something genuinely urgent. Using it for routine confirmations makes the page talk over its own user, which is worse than not announcing at all.

The region has to be present and observed before the message arrives, so inserting the container and its text together usually announces nothing. It is the commonest reason a correctly-marked live region appears not to work.

Two roles carrying implicit politeness settings, which makes them shorter to write and easier to get right than the attributes they imply. Choosing between them is the same judgment as choosing the politeness level, expressed once in the role.

An alert announces without taking focus, which is what distinguishes it from a dialog — the user's place in the page is preserved. Reaching for a dialog to make sure a message is noticed is how an interruption becomes a disruption.

A client-side navigation changes the content without any of the events a real navigation fires, so nothing is announced and focus stays where it was. Announcing the new page and moving focus deliberately is work the browser used to do for free.

Four obligations: move focus in, keep it inside, close on the escape key, and return focus to whatever opened it. The last is the one most often omitted, and its absence strands a keyboard user at the top of the document after every dialog.

Everything behind a modal must be unreachable by tab, by a reader's browse mode and by pointer — three separate mechanisms, which is why hiding it one way is not enough. A dialog whose background is still readable is not modal for the people who most need it to be.

The platform element supplies the top layer, background inertness and escape handling without custom code, which removes most of the ways a hand-built dialog goes wrong. Reaching for it first is the same principle as preferring any native element.

One button, one state attribute, and no focus movement, which makes it the simplest interactive pattern that can be built correctly. Most expand-and-collapse interfaces want exactly this and reach instead for something with a keyboard contract they then have to implement.

Exactly one child is in the tab order at a time and the rest are reached with arrow keys, which makes a composite widget one tab stop rather than many. It requires updating the attribute as focus moves, which is the part implementations forget.

Document focus stays on the container while a reference marks which option is virtually focused, which suits a widget where the user types into one element and navigates another. It is the alternative to moving real focus, and the two must not be mixed.

The input keeps focus, arrow keys change the active option, and escape restores what was typed — a specific set of behaviors users have learned from the native equivalent. Deviating from it produces something that looks familiar and behaves unpredictably.

The menu role promises an application menu with arrow-key navigation and a specific keyboard contract, which a list of page links is not. Applying it to site navigation makes a reader announce a widget whose promised behavior does not exist.

Readers intercept keystrokes while browsing and pass them through while in a form control, which is why a custom key binding works in one mode and not the other. Knowing the two modes exist explains most reports of a shortcut that mysteriously does nothing.

The reader works from a snapshot of the page rather than from the live document, so a change that fires no notification is simply not present in what the user is reading. That is the mechanism behind live regions and behind the failures that look like content being ignored.

People jump by heading, landmark, link and form control far more than they tab through a page in order, which makes those structures navigation infrastructure. It is also why a page's outline matters more than its tab order for a reader user.

Commands are spoken as the words on screen, so a control whose accessible name differs from its visible text cannot be activated by naming it. That is the practical consequence of overriding a label with different words, and it affects a whole input method rather than one user.

At high magnification only a fraction of the viewport is visible, so a confirmation appearing far from the control that triggered it is never seen. Proximity between an action and its feedback is an accessibility property, not just a design preference.

The operating system replaces the palette outright, dropping background images and any meaning carried only by color. Designs relying on subtle background tints or colored borders lose exactly the information they were carrying, which is why testing in it finds real failures.

Rule engines detect a minority of failures and cannot judge whether a name is meaningful, whether an order preserves meaning, or whether an alternative conveys the right thing. A clean automated report is a floor rather than a result, and treating it as a pass is the commonest process failure.

Putting the pointer away and working through the page checks reachability, visible focus, sensible order and the absence of traps in one pass. It requires no tooling and finds a large share of real failures, which makes it the highest-value manual test available.

The computed name, role and state are the actual contract with assistive technology, and browser tooling shows them directly. Checking there rather than reading the markup settles questions about which naming source won and whether an attribute took effect.

The published methodology scopes, samples, explores and reports rather than attempting every page, and it samples states as well as pages. That last part matters — an error state, an empty state and a loading state are different content and are routinely untested.

A script injected at load cannot repair semantics it did not author: it can guess at names and roles, and a guess is exactly what the wrong-ARIA rule warns about. They also frequently interfere with the assistive technology the user already has configured.

Watching disabled people complete real tasks is the only evidence that the whole thing works rather than that each part passes. It routinely finds problems no criterion describes, because conformance and usability are related and not the same question.

The criteria are written to be technology-neutral, so they apply to native applications with different techniques rather than not applying. Treating accessibility as a web concern is how a native app ships with none of it, since the platform requirements are the same.

Platforms expose the same triple through per-view properties rather than through markup, which means the concepts transfer directly and the mechanics do not. Someone who understands the accessibility tree already understands what the native API is doing.

Honoring the system text-size setting is the mobile equivalent of the resize requirement, and the failures are the same — fixed heights, clipped containers, truncated labels. The setting is widely used, which makes it one of the highest-impact things to test.

Merging a card's parts into a single accessible element reduces the number of swipes to traverse a list from many to one per item. On a long list that is the difference between usable and exhausting, and it costs one grouping property.