W3C Working Group Discussions

A requirement is only useful if authors can apply it and two testers reach the same verdict. CSS px is defensible as the anchor because it is defined by visual angle rather than physical pixels, so it is device-independent. Browser zoom — the default control, persistent across sites — is the user's route to larger text, so a minimum size plus available magnification is judged sufficient.

CSS font-size is a poor proxy for legibility: x-height and stroke weight vary enormously between typefaces at the same nominal size, and rendering differs by OS and font cut. sdw32 points to the EN 301 549 draft, which gives an x-height of at least 8 CSS px for the smallest text as best practice, and proposes handling weight by pixel density rather than the binary normal/bold split. Myndex argues a test that is merely testable, without being useful, gets codified into law with unintended consequences. Myndex nonetheless defends the CSS px, defined by visual angle, as the right reference unit for guidelines, with x-height rather than font-size as the measure.

px ignores a user's configured root font size while rem respects it, so anchoring the standard in px effectively tells the market that overriding user preference is acceptable. chaals lands in the middle: provide both a baseline that conveys a commonly legible absolute size and clear guidance that resizing must actually work — and reports from browsing ~100 pages at 64px that most sites, news sites especially, become unusable, which he attributed mainly to layouts set in pixels.

"Does not use a decorative or cursive font face" is called subjective and over-broad. Finnberrys, a voice-recognition user, wants underlining restricted to links because randomly underlined text repeatedly reads as a link. julierawe wants "most text" defined before the requirement can be tested.

x-height does not translate to Japanese, Chinese or Korean, so any text-appearance metric has to be checked against non-Latin writing systems before it ships in a global standard.

WayneEDick's original issue (wcag21#846, copied into #198 by michael-n-cooper) showed screenshots of content squished between a fixed header and footer, arguing the low-resolution assumption is a phone in portrait while a low-vision user is actually in landscape, and that non-collapsible vertical panes growing with zoom leave no usable space. StommePoes says these are simply non-functional pages: at 150% on a 12-inch laptop she gets about three lines of text, and she names Medium.com and news sites as the worst offenders, failing them under text-resize in her own audits. mraccess77 adds breakages with the same cause — hover content that appears off-screen and vanishes when you scroll to it, snap scrolling that jumps past content you are trying to reach at zoom, and scroll jacking that takes away ctrl plus mouse wheel. All three treat the fix as cheap and known — WayneEDick's three techniques are switch fixed to static at low resolution, replace the bar with a control limited to 10% of the screen, or make it collapsible, and StommePoes adds that developers already write width-based media queries, so a height-based one in ems can simply drop the stickiness, since the sticky content is usually the site name or social buttons.

patrickhlauke would support a percentage or ratio rule — roughly, sticky and fixed elements not covering more than a third of the visible viewport — with the understanding doc requiring testing in both portrait and landscape, down to 320 CSS px width and 256 CSS px height. He insists on "down to" rather than mandating that exact viewport dimension, because otherwise the requirement is pointless. StommePoes agrees, citing content that passed at 400% on a 1280 px viewport but broke around 250% when a media query did not fire, leaving the user to choose between 175% (too small) and 300% (larger than needed); she also reports that showing designers sticky elements eating a quarter to a half of viewport height draws no pushback, because they find it ridiculous too.

Sticky headers create reading viewports that are too short, but mraccess77 doubts the group can reach consensus on what height is acceptable: is the metric percent of viewport height, or the number of lines of text that fit? Full coverage is clearly a failure, but two or three visible lines forcing the user to read through a slot is harder to draw a line around. He notes the LVTF concluded these issues were too challenging for WCAG 2.2's framework and belonged in Silver, and that the working group's impression is that low-vision issues are already solved — leaving him unsure which spec is the right home. alastc was more optimistic, suggesting a limit could build on reflow's existing 256 px minimum height and tie in with device orientation.

PAFaieta opened #156 asking that the standard name a baseline native viewport resolution and DPI, or a baseline minimum magnification such as 200% as a satisfactory technique, on the grounds that vague language invites compliance arguments. patrickhlauke answered that CSS px is already density-independent and that authors cannot predict or test the physical resolution and dimensions users run — a person on a physically small monitor at very high resolution has chosen that, and adapting the device is their call, not the author's. alastc added that WCAG 3 deliberately avoids technology-specific language at the provision level and expects metrics to live in technology-specific methods, and asked for concrete ground-level examples of the "liberties" being taken; PAFaieta left the thread without supplying them.

chaals set font-size to 64px in Safari and browsed roughly 100 pages: news sites were generally unusable (abc.net.au the least bad), search engines were terrible, whitehouse.gov and un.org worked reasonably, and idealista was the one usable shopping site. He reports that pretty much every serious problem traced to layouts set in pixels — most commonly line-heights derived from the screen's pixel width and far below 64px, then large text squeezed into too-small boxes. His proposal is to trigger breakpoints on character counts rather than screen width in px, and to express any measure larger than half the expected font-size in rem, with layouts expected to work between 4px and 72px (about 1.5mm to 25mm). graphic-designer (#642) argues the same conclusion from user autonomy: px ignores a user's configured root font size, so a px-based architecture is rigid by construction while rem lets the layout breathe.

Responding to #642, alastc says WCAG 3 has no mention of 16px, that its only CSS px requirements are text resizing to 200% of the platform default body size and text reflow at 320 CSS px, and that CSS px is itself relative to an assumed viewing distance and translates to platforms that have no rem. He argues browser zoom is the default, easier-to-find setting that persists across sites, that text-only sizing breaks text out of layouts, and that sizing the whole layout in rem just re-invents zoom; his draft response would close the issue without changing provisions. Myndex says the CSS px is defined as a unit of visual angle, which is what vision science uses, while rem has no fixed relation to it, and that Chrome is the only major browser he knows with an independent default font size setting. GreggVan says rem says nothing about how large something is, so an accessibility minimum cannot be written in it, and that CSS px values are cited in standards only as minimums. chaals, after testing, agreed zoom works better than increased text size on most sites, while still seeing a use case for text-only sizing to keep headings and images from becoming unworkable.

An emailed objection from an unnamed sender, which alastc posted as #664, argues that forcing a 320 px mobile-style layout on a desktop display at 400% zoom increases cognitive load for older users by hiding familiar navigation and breaking established mental models. It claims this breaks complex interfaces such as legal document portals, preventing citizens from accessing documents, and characterises the mobile-first target as favouring the ecosystems of major W3C corporate members. The request is for a Desktop-Preservation Mode or a reduced requirement — 200% — that does not trigger a full layout change. Nobody has replied.

The starting point is ericwbailey's framing in #238 that an abled content author deciding what counts as decorative removes agency from the person using assistive technology, with a case he met in the wild (photos of amenities for luxury housing classed as decorative even though they communicate the benefit of living there); ericwbailey himself did not call for abolition, and suggested tempering the point by testing with the intended audience. brett-oppegaard goes further in #369 — a designer told him a stock photo of a diverse group reading books in front of a university building was decorative and therefore not legally required to be described, and he has heard the same claim made about portrait photos of organizational leaders. His argument is that visual designers always have the option not to include an image, so every included image has a rhetorical purpose; that a screen reader user can skip alt text with a single keypress, so the audience should decide, not millions of decentralized, busy, often untrained site managers; and that the loophole is why Instagram alone emits 70,000 mostly undescribed images a minute. He also wants the term "alt text" retired in favour of static Audio Description, which he argues separately in #371 (see image-alternatives-available). charleshalldesign takes the same line in #878, proposing to retire the concept completely on the grounds that all images convey information, and that an image next to text, in a control or not, supplements the text rather than duplicating it.

TestPartners reports content creators over-compensating with literal descriptions of decorative images running to several sentences and as much as 50 words, which a screen reader user must sit through a large proportion of before concluding it is fluff they did not need; he puts community opinion at roughly 50:50 and says a substantial majority should exist before anything changes. He half-seriously proposed a CSS prefers-reduced-fluff property as the only way to satisfy both camps, and rejects the premise that undescribed decorative images discriminate — you may as well argue that hanging wallpaper discriminates against people who cannot see it. patrickhlauke's reductio in #238 is that if every non-text piece of information must be conveyed, authors would have to describe colour and sizing choices and ultimately the entire CSS of the page, so a pragmatic and admittedly subjective cut-off is unavoidable; he adds that where a flourish exists to convey a mood, prose carrying the same tone can already be an acceptable alternative. bruce-usab makes the placement argument against Myndex's paisley example: the fact that paisley patterns descend from Jacquard-loom punch cards is compelling trivia that belongs in the footer or on an About page available to everyone, not buried in an alt attribute forced only on screen reader users.

yatil's objection in #369 is that WCAG has said "pure decoration" since 2008 and merely being decorative never qualified for the exception — WCAG comes from the era of image-rendered container shadows and image-replacement headings, and most genuinely pure decoration can now be done in CSS. He argues the draft's test, whether removing the image would impact how people understand the page, is far too low a bar: under it a portrait in a staff index is decorative and so is a news article photo, and neither "impact" nor "understand" is defined. lauracarlson opened #238 on the narrower charge that "Decorative Images" is broader than "Pure Decoration" and that conflating them is a mistake; her specific target is the Method's "Illustrative of adjacent text but not contributing information (eye-candy)" line, and she proposed renaming "Decorative" to "Purely Decorative" throughout. She calls null alt a hangover from the spacer-gif era; bruce-usab agrees null alt is overused, though he says his own sampling shows missing alt and low-information alt attempted as textual equivalence remain the bigger problems, while allowing this may be sampling bias. In #878 yatil asks the group to stick to WCAG 2's pure decoration definition, since both standards will be used in parallel for years, and says the linked-card examples raised there fall under the Controls, Input exception instead.

MakotoUeki opened #466 proposing an explicit split: purely decorative images (an icon alongside text, a thumbnail inside a link) need no text alternative and should have no accessible name, while decorative images (a photo, an illustration) may usefully carry one as a best practice. The user need he cites is a person who lost their sight later in life and wants the description in order to picture the image, and his position in #238 is that the user, not the author, should decide whether something is meaningless. fstrr points at a ready-made middle category: the HTML spec's ancillary images, where an image is neither purely decorative nor entirely redundant with the text, the alt attribute must be present, its value may be the empty string or a textual representation, and it must not be empty when the image has a caption.

grace-snow's reply in #466 is that if an image adds meaning it is not decorative at all, so naming a class of "decorative" images that do need alternative text is highly likely to confuse; whether a photo or illustration is decorative depends on the surrounding content and context, not on the image type. Finnberrys agrees and offers the substitution test she applies: a swirly line at the bottom of a page could be swapped for a wiggly rainbow line with no effect on content, whereas a photo of her dog on a page about assistance dogs could not be swapped for a unicorn without becoming confusing and weird. sydneycolemanfromgoogle filed the same objection independently in #518 — the distinction is not useful without a clear and mostly objective means of telling the two apart.

mraccess77 reports that Internet Explorer's exposure of alt as a tooltip let him learn things about images he could not distinguish visually — essentially audio description for the web, the nuances low-vision users miss — and notes that captions today are available to everyone rather than only to deaf users, while accessible name and description are not. Myndex makes the adoption argument: alt text is effectively unreachable outside screen reader use, and if it surfaced through a standard user-agent affordance it would serve people with prosopagnosia or other cognitive and contextual needs, reader mode, and failed image loads, and the broader demand would drive adoption. bruce-usab counters from history that IE's tooltip behaviour is precisely what trained authors to write tooltips into alt for years, that the TITLE attribute only partly separated them, and that the practice only corrected when touch UIs removed the tooltip, though after mraccess77's reply he allowed he was probably overstating the harm and that some human-written alt is almost always better than none. Myndex also flags that CSS background images accept no alt text at all, which he treats as a missing platform property rather than an author failing.

#878, opened by alastc on 2026-09-29 after vavroom's article on retiring decorative images, is where the definition argument now runs. alastc floated redefining it as not contributing to the information, functionality, meaning, mood or context, then asked whether not relied on would be better after patrickhlauke noted that mood can also be carried by the tone of the text. lauracarlson revived her purely decorative proposal, with a definition excluding anything that provides meaning, context, mood or user understanding, and with alastc reframed generic card images and linked thumbnails as duplicative rather than decorative. MakotoUeki, facilitating the subgroup, said it will not stick to WCAG 2's definitions and wants to gather concrete examples. On verbosity, alastc reports screen reader users split between wanting descriptions and wanting to get on with the task; patrickhlauke warns that requiring alternatives for most images will produce LLM-generated descriptions and distinguishes an alternative from an on-demand description; mraccess77 argues that alt on every image without importance metadata, such as an aria-important attribute, would leave users no way to control verbosity, and cites invisible email tracking images as genuinely ignorable. LJWatson and vavroom answer that content that is present can be skipped while absent content cannot.

CSS px is relative to assumed viewing distance, which is what lets a requirement say how large something must appear across platforms. alastc notes WCAG 3 does not currently use px or rem for text sizing at all, and drafted a response proposing the issue be closed without changing any provision. GreggVan argues rem only says how big something is relative to something else, so an accessibility requirement cannot be written in rem because it sets no minimum size, and adds that px has only ever been cited as a minimum, not a fixed size. Myndex adds that the CSS px is defined as a unit of visual angle, the measure vision and readability science uses, while em and rem have no fixed relationship to it; using rem in practice is fine, but guidelines should trace to visual angle.

A user who sets a larger default font size sees rem-based layouts adapt and px-based layouts stay rigid. Argues this makes px a technical regression against user autonomy, and that calling it a user-agent problem shifts responsibility away from the standard.

Neither layout stability nor user scalability is the goal — people being able to read what is published is. Tested the disputed demo across Vivaldi, Avast, Safari and Firefox and found the px box adapts in some Chromium builds and not others, so the behaviour is not uniform. On the unit question itself he leans toward rem: asked whether px makes sense as a core unit for layouts rather than rem, his answer is "generally not"; he tells GreggVan an accessibility statement based on rem is perfectly feasible; and after browsing about 100 pages at a 64px font size he traced most serious problems to layouts set in pixels, concluding that promoting rem instead of px would really help. He also wants a reasonable default text size stated. Proposes a separate issue: content should support text-size adjustment well beyond the current 100–200% range.

On the related question of high-DPI viewports, raised in #156 by PAFaieta, who suggested a baseline native resolution and DPI or a baseline minimum magnification such as 200%, patrickhlauke replies that authors cannot predict or test the physical resolution a user runs, so a guideline cannot introduce that variability. A user running a small monitor at very high resolution has made that choice and can adapt their device.

cstrobbe's proposal in #166 would require that elements used with their native roles be nested according to the content models in their specifications, plus a fourth clause barring links, interactive elements and keyboard-focusable elements as descendants of links. He worked through seventeen code examples (numbered 1 to 16, then 19) showing where a syntax reading of 4.1.1, a validation reading, and the proposal each land — button wrapping an anchor, li inside a div inside a ul, p as a sibling of li, h2 wrapping p. JAWS-test called it exactly what was needed and asked that it also cover ARIA and PDF tags, noting that correct nesting is what lets a screen reader report that a table has 3 columns and 2 rows and that you are in column 2, row 1. JAWS-test cited EN 301 549 clause 11.5.2.9 and Section 508 502.3.7, both of which already require parent-child relationships to be programmatically determinable.

patrickhlauke would rather see 4.1.1 updated normatively in a backwards-compatible way than patch around a poorly interpreted criterion, warning of weird overlaps where one SC is a stricter special case of another. yatil proposes extending 4.1.1 to "markup languages and associated extensions as they relate to accessibility features" and dropping the well-formedness framing from the Understanding document, or alternatively removing 4.1.1 entirely per w3c/wcag#2676. scottaohara agrees: use 4.1.1 for what people think it is for, unless "elements are nested according to their specifications" does not actually mean that. patrickhlauke also argues the singling out of links is arbitrary, since buttons and other controls have the same problem.

bruce-usab says it is bad to retcon a standard and refuses scottaohara's "use 4.1.1 for what people think it's for" framing; GreggVan agrees and adds that 4.1.1 should be clarified to mean what the working group meant when it was written, not what people later want it to mean. bruce-usab separately notes the proposal arrived too late for WCAG 2.2. cstrobbe's own reply is that the intents differ: 4.1.1 is about a user agent building an unambiguous parse tree, while his proposal is about name, role, state and value being exposed unambiguously through an accessibility API, which puts it closer to 4.1.2.

detlevhfischer's #194 proposal caps the gap between a label and the element it labels at twice the smaller of the labelled element's width or height, illustrated with a 16 px-tall field passing at a 32 px gap and failing at 33 px. He later revised it to four times the smaller dimension of the label itself, to escape the problem that the original formula breaks for textarea. mraccess77 defends the need against demands for evidence, pointing out that the SC 3.3.2 Understanding document said in 2008 that labels close to their field help screen-magnifier users, that G162 already exists, and citing Nielsen Norman Group material on proximity and form white space; to the argument that proximity gaps are a common pattern he answers that "because something is a common pattern doesn't mean it's a correct pattern."

jake-abma checked with designers and reported that almost all current forms would fail and that the calculation is too prescriptive for design aesthetics, and that the measurement scheme — four times, three times, widths, heights, mixed elements — is too complicated for designers, developers and testers alike. awkawk points to the very common pattern of left-aligned labels against aligned fields, where varying label length forces varying gaps, and says disallowing a common pattern requires clear evidence. alastc notes the proposal would fail the GOV.UK Design System text input with hint text, and asks what happens when an error message is inserted. patrickhlauke finds the loophole immediately: a designer could make fields excessively tall purely to buy leeway to push the label further away, defeating the point while passing; he also asks for hard proof that larger gaps harm particular users rather than the working group making things up. detlevhfischer concedes the exception list grows until the original requirement is lost, and that focusing on label-to-control catches only a subset of the proximity problems he has seen in low-vision user testing.

In #451 GreggVan argues that if a relationship is not presented to anybody, it is unclear what the requirement is getting at, and that without scoping there are a million ways elements can be related and all of them would have to be conveyed programmatically; he proposes narrowing it to "when relationships of meaning between elements are presented visually, they are also conveyed programmatically." giacomo-petri opened the issue acknowledging the tests are incomplete and that the requirement must either gain sufficient tests or state its applicability clearly. adampage's specific gaps are error messages and help text for form controls, and tables with headers, bodies, footers, data cells and header cells — questions that arise precisely because the written tests are so narrow.

sdw32 says he was surprised to find the words "contrast ratio" still in the latest WCAG 3 draft, because there is neither empirical nor theoretical evidence that the eye perceives contrast in proportion to the lightest colour divided by the darkest; the evidence supports perception of a brightness difference, which is what APCA computes. He argues that for mobile devices in typical indoor lighting the eye adapts to the room, so the difference can be used directly without normalising against an average or ambient level, and points to his cedc.tools comparison of APCA against ratio for black and white text on coloured backgrounds. Myndex adds in #29 that 4.5:1 degrades the experience for 100% of sighted users rather than only impaired ones, that roughly 86% of sites fail WCAG 2 contrast on automated survey with some of those failures being perceptual artefacts rather than real inaccessibility, and offers a side-by-side dark-mode comparison in which the WCAG 2 minimum is unreadable while the APCA minimum is legible.

Issue #29 exists to answer the Contrast Subgroup's condition that APCA needs extensive peer review before adoption. Myndex's position is that peer review is not in the WCAG 3 charter and no other subgroup has been asked for it, and that APCA has been in open public beta since the stable February 2021 release regardless. The dossier lists journal and book-published work (Ulitin in Culture and Technologies Studies 2021 and a 2023 Springer chapter), Sam Waller's Cambridge paper "Does the contrast ratio actually predict the legibility of website text?", Chris Lilley's internal W3C review in the silver repo, and a Low Vision Task Force thread involving Bailey, Campbell and Avila. He renews a 2020 proposal that AGWG convene a standing panel of subject experts on the SMPTE or ISO model, on the grounds that it would strengthen the standard's footing in future legislation.

GreggVan does not dispute that stroke weight, font design, presentation time and anti-aliasing all affect reading; he says stem width was considered and dropped because most people cannot measure it, and that the current simple measure is a deliberate trade, not an oversight. What he wants from critics is proposed wording: a single statement of the musts and a second of the shoulds, where a must is important, works across web technologies and has good interrater reliability. Machine testability is not required, only enough objectivity that different evaluators reach the same conclusion. He offers to have a "text visibility" tool built that takes font, size, type, stem and height and returns a linear score against a pass threshold, with a different threshold for running text than for menus, buttons and other short strings where the reader has time to fixate.

Direct rebuttal to the testability framing in #266: if the result of the test lacks utility then making it testable has not helped, and because WCAG 2.x is now being written into law, a flawed test carries flawed consequences with it. He offers the APC-RC reference-font matching method as a simple testable alternative, where a designer matches their chosen typeface against reference fonts for the silver and gold levels, necessary because "normal" and "bold" mean substantially different things per family. He also disputes GreggVan's premise that authors will not handle multiple variables, saying designers work with x-height ratio and glyph weight routinely and prefer a range of options to a binary, and that in practice only the critical content text needs testing, body text above all, and only once.

sdw32's glance-readability study, about 40 participants shown random three and four letter words for 300 ms across Open Sans Light through Extra Bold at APCA Lc 30, 45, 60 and 75, found that the minimum workable font size depends on the interaction between weight and contrast: Open Sans Extra Bold at Lc 30 outperformed Open Sans Light at Lc 75. His proposed fix is to quantify weight by pixel density after Wilkins, rasterising sample text, cropping to the x-height and thresholding at RGB(128) to split the anti-aliased pixels; using Wilkins' "the quick brown fox" phrase that gives Open Sans Light 20.2%, Open Sans 30.7%, Open Sans Semibold 40.0%, Open Sans Bold 47.5%, Open Sans Extrabold 56.4%, with Arial 35.4% and Verdana Bold 50.3%. He later proposed switching to the bare alphabet so the method generalises beyond Latin, without publishing revised figures. TestPartners notes WCAG 2 recognises only 400 and 700 while weight 600 is common and reads as bold. patrickhlauke's objection is upstream of all of it: the same nominal CSS weight renders differently between typefaces and even between cuts of one typeface, so the value is meaningless unless anchored to specific font metrics, which font fallback then breaks.

In #590 nakano0949-web proposes a rendering-aware model: a rendered glyph divides into a Core of pure glyph colour, an anti-aliased band of blended pixels, and a background ring, with Core Ratio approximated as (C/W) squared and AA Impact as 1 minus that. Measurements show AA impact climbing sharply below 14px and dominating at 12px and below, so text that passes on CSS colour values can measure substantially lower as actually drawn, worst for small sizes, thin weights and particular font cuts. The proposal supplies a five-step extraction algorithm to automate the measurement and offers data and code. patrickhlauke cross-references the earlier w3c/wcag#4954 discussion and elsewhere in #266 lists the same class of variables the model is trying to capture: OS anti-aliasing settings, font substitution, differing cuts, and the period when macOS rendered fonts visibly fatter than Windows in the same browser.

The WCAG 2 equivalent sits at AAA, which in practice means it is ignored. If a user has set prefers-reduced-motion, respecting it should be required, not aspirational. guyhickling argues a mechanism to stop animation is no help when the harm lands before the user reaches the control — particularly for keyboard users.

prefers-reduced-motion is a single binary flag, but users are usually affected by specific kinds of motion, and the setting is sometimes enabled accidentally. Treating it as "turn off all animation" is too draconian for a normative requirement and risks developers writing WCAG off entirely.

Defining size and duration across devices and zoom levels is where this previously broke down, and duration is undefined when the motion is triggered by user action such as scrolling. Moving it to a base level requires evidence of impact at a given size and speed, and a consensus process means persuading those who objected last time.

A study demonstrating harm from motion would harm its participants. Also argues the need is broader than vestibular illness: hyper-vigilance and attention impairments mean even small, sub-second animation costs time and mental energy to recover from. alastc replied that such a study need not force anyone to view animations — participants could log the animations they encounter and the symptoms triggered — and that whether there is an impact is believed and understood; the question is what specifically triggers symptoms.

Proposed "Label gaps" in #194: when one element acts as a label of another, the gap between them is no larger than twice the smaller of the labelled element's width or height, measurable with a browser ruler or a script comparing absolute positions. When textareas broke that formula he reworked it to four times the smaller dimension of the label itself, so an icon or short text label sets the budget rather than a large field. He cites repeated findings in his own user testing with low vision users — drop-down menus on accessuse.eu and the incobs tablet tests — while conceding the label-to-control pair catches only a subset of the proximity problem, and that the exception list may grow until the requirement is lost, as happened with target size.

Found the loophole immediately: a designer could make fields unnecessarily tall purely to buy leeway to push the label further away, conforming while defeating the point for low vision users. detlevhfischer answered "not likely to happen"; patrickhlauke replied that creative interpretations of normative text to do the minimum necessary to pass are routine. His broader position is that layout and design questions resist rigid binary pass/fail rules, that Apple's own iOS guidance is couched as could and should and Apple ignores it freely, and that this belongs in a non-normative best-practice note or at AAA rather than as a hard requirement. He also asked that the measurement drop mm for px to avoid reopening the CSS-versus-physical-units confusion, which detlevhfischer did immediately.

awkawk points to left-aligned label columns with aligned fields, where varying label lengths necessarily produce varying gaps, and argues this is common enough that the working group needs clear evidence before proposing a criterion against it — this is not an absolute like page title or programmatic label association. He wants the goal stated first: at what magnification must the user see the full label and the full input, or the full label and part of the input, and what happens when the label is long. jake-abma checked with designers and reported back that almost all current forms would fail the proposed calculation, which he called too prescriptive for design aesthetics, and later that mixed 3x and 4x width-or-height measurements are simply too complicated for designers, developers and testers.

Answers awkawk that clear evidence only ever comes from research, and the group has a chicken-and-egg problem when practitioner experience outruns formal study. Cites the Understanding document for SC 3.3.2, which stated in 2008 that labels in close proximity assist screen magnifier users because field and label are more likely to be visible within the magnified area, plus technique G162 and two Nielsen Norman Group articles on closeness of actions to objects and form white space. Turns the evidence demand back on existing criteria by questioning whether page titles are still demonstrably useful when browsers truncate or hide them. Calls awkawk's own screenshot a prime example of the problem: a common pattern is not thereby a correct one.

patrickhlauke suggested a minimum built on reflow rather than ratios: the related element must be at least partly present in the viewport even at 320 CSS px width. jake-abma picked this up as the direction most likely to work — label and input visible in a 320 CSS px viewport at the same time, easy to test, with exceptions. He also supplied its limits: whether the label is visible depends on how far you have scrolled, something can be inside the viewport and still too far to read, and desktop zoom tools push the label off to the right and force horizontal scrolling, so the desktop case stays unsolved.

alastc showed the formula failing a usable pattern — the GOV.UK Design System text input with hint text between label and field, and again when an error message is inserted — then proposed folding associated information into the definition of label, and a looser framing that two related things must be close to each other unless there is a programmatic relationship, with gestalt principles consulted for what close means. He intended the escape hatch to leave room for a future user agent that draws an arrow or indicator, and suggested the COGA task force's design guidance as the better home. patrickhlauke rejected both halves: if the requirement is visual then a programmatic relationship is irrelevant to a user who is not running AT that exposes it, shifting the burden to user agents is a cop-out, and since programmatic association is already required by 1.3.1 and usually 4.1.2, a criterion satisfiable by passing those is redundant. jake-abma agreed on widening, arguing all name-value pairs and many other related pairs deserve the same treatment.

In #890 (October 2026) mcking65 proposes removing the programmatically available requirement from this provision, rewording it as "Names (including labels) that identify the purpose of the interactive element are visually persistent", and moving programmatic names into Roles, values, states, properties available, reworded so those attributes are "reliably" programmatically determinable. His grounds are that visual and API testing are separate processes, often by separate testers, and that bugs are easier to route when a provision clearly concerns visual design or code. GreggVan objects that "reliably" cannot be defined to mean matching the visible label and is not an objective term, that names do not include labels — labels have meant what is visible and names what is programmatically determinable — and that the name often should say more than the label, as with ON/OFF buttons whose association is visually obvious. He asks the group to start from desired outcomes for users without vision, with good vision and with low vision (and cognitive needs if not covered elsewhere), then decide whether this is one requirement or two.

Myndex rests his argument on Lovie-Kitchin's critical contrast, the point past which further increases in text-to-background contrast produce no improvement in reading speed or comprehension. Once a design reaches that Lc level it enters contrast constancy, and from there the spatial factors — whitespace, stroke weight, size, crowding — govern readability, with the perceived luminance difference ranking, in his words, among the least important. He cites Chung and Tjan for the mechanism: reading speed shows strong spatial-frequency dependence when text contrast is low, which is to say the payoff from added contrast is conditional on size and weight rather than additive to them. sdw32's glance study, which tested APCA Lc 30, 45, 60 and 75, supplies a matching data point, with Open Sans Extra Bold at APCA Lc 30 outperforming Open Sans Light at Lc 75, from which he concludes a single contrast threshold for all font weights is not fit for purpose (the weight-quantification method behind it is covered under text-contrast-sufficient-minimum).

Myndex's #207 restructure groups 1.4.3 Contrast (Minimum) and 1.4.6 Contrast (Enhanced) under one guideline, "Visually readable content uses ample luminance contrast," keeping 1.4.6 as its own row and attaching to it 1.4.6a on font weight and glyph characteristics and 1.4.6b on text use cases. His categories are FLUENT — high-fluent body text, defined as more than two continuous lines in a block or column at an x-height of about 16px or less, fluent text up to two and a half lines, and large fluent headers above about 32px — and SUB-FLUENT, covering soft readability, spot readability (readable with fixation), logo and branding colours, and incidental text in images. GreggVan, in #266 and without reference to the enhanced level, proposes a text visibility tool with one pass threshold X for running text and a different X for menus, buttons and other short strings where the reader has time to fixate.

Answering sdw32's question about minimum size and contrast requirements for default presentation, GreggVan's position is that if a size is large enough for typical vision, then that size under magnification is good enough for low vision — large print for typical viewers is large print for low vision users, fine print is fine print, and anyone with very low vision has magnification built into every OS. He adds that stating any floor would require specifying screen size and CSS pitch, which the author does not control, and says a lot of thought went into concluding there is no way to guarantee text is never too small.

sdw32 rejects the premise of typical vision outright — vision is a bell curve like grip strength, and he routinely measures young people at 20/10, twice the 20/20 reference. Since designers default to designing for themselves, a site built by a 20/10 designer accommodates only 20/50 at the browser maximum of 500% zoom, which he does not accept as maximising foreseeable use. Working backwards from 20/200 access at 500% gives a target of 20/40 suitability at 100%, which is his 8 CSS px x-height floor. On GreggVan's pitch objection he answers that no screen pitch need be specified, only the CSS px definition itself — 96 DPI viewed at 28 inches or 711mm, implying 427mm for a 160 DPI phone — and offers a live failure, the string "achetés = 30% d'économies" on carrefour.fr, as text that fails EN 301 549 while passing the current WCAG 3 draft. The minimum-level half of this exchange is covered under text-contrast-sufficient-minimum and text-style-readable-minimum.

EN 301 549 v4.1.0, which sdw32 worked on, already ships the two-level structure but keys it to whether the text can be enlarged rather than to a conformance level. Zoomable text gets a best-practice x-height of at least 8 CSS px, corresponding to 1.2mm at a 400mm viewing distance with no zooming or screen scaling; text and images of text necessary for all functionality that is closed to text enlargement get at least 16 CSS px of x-height, an exact doubling. The weight rule he wrote for the separate non-digital standard interpreting the European Accessibility Act is two-sided rather than a floor: body text between regular-weight and semi-bold Open Sans, and keywords or short phrases neither thinner than regular Open Sans nor heavier than extra-bold.

APC-RC carries silver and gold levels with reference fonts a designer matches their own typeface against, and Myndex states the selected contrasts for both are intended to serve a Pelli-Robson score down to 1, a profound contrast deficit on a scale where 2 is normal and lower is worse. That makes the higher tier an answer to a measured population rather than a round multiple of the minimum. nakano0949-web pressed him in #590 on whether APC-RC addresses colour vision deficiency and low vision, which she said physical contrast models alone cannot fully capture; Myndex answered that APCA already improves on WCAG 2 for protans, that a protan compensator pre-shaping luminances for colours with high red primary content is due this year, and that SACAM, an accessibility-adjustable colour model for dynamic personalisation, is in progress. In #207 he notes the same physics already rejects pure red against black or dark colours, since red on black is poor for standard vision too.

CharlesBelov's original ask (#183) was that where the OS exposes the request and the user agent passes it to content, not animating should satisfy AA — the user telling their OS that animation is problematic removes the need for anyone to decide whether a given animation is problematic. guyhickling points out that Android's "Remove animations", iOS's "Reduce motion" and Windows 10's "Show animations" are all binary switches that set the same flag, and that honouring it costs an author a media query rather than banning animation, with an opt-in button available where the animation is genuinely informational. mgifford and guyhickling both argue AAA is where requirements go to be ignored, because AA is the norm most IT teams work to. CharlesBelov later adds that the need goes beyond VIMS to hyper-vigilance and attention impairments, where even small, sub-second animation costs focus, and asks to be believed that an OS-level request is sufficient without waiting for a study.

prefers-reduced-motion is one bit, but users are affected by specific magnitudes and kinds of motion, so reading it as "no animation at all" would technically fail a page containing a single dot that fades by one opacity value. He cites Windows users who set the preference accidentally without realising what it does. His counter-proposal, building on mgifford's #182 suggestion that respecting user choices such as dark mode be at least AAA, is a generic "respect user settings" requirement at AAA covering dark mode, reduced motion and high contrast, phrased in Understanding rather than hard-coded to whichever media queries exist today, with honouring a preference offered as a sufficient technique rather than the normative bar — and even then subject to whether it is accessibility supported.

Specifying size across devices and zoom levels, and duration when the motion is triggered by user action such as scrolling, is exactly where this stalled during WCAG 2.1. Small animations such as icons changing on hover did not appear to be vestibular triggers, so a minimum size looks necessary before the requirement can sit at A or AA. The preference is not a 1:1 fit for the user need, so relying on it produces false positives and extra work; in a consensus process that means persuading the people who objected last time. Answering CharlesBelov's invocation of the W3C Code of Conduct, he redirects to the priority-levels wiki as the document that actually governs level decisions.

JAWS-test's cross-browser test of prefers-color-scheme (#182) found Edge reporting light even in Dark Mode and dark only under high contrast white-on-black, Firefox reporting light even in HCM, Chrome mapping some HCM modes to dark and others to no-preference, Android Chrome always reporting light even in Dark Mode, and only iOS Safari behaving as expected. mraccess77 reports the Windows setting blocks animations they want along with those they do not, and asks for finer control. MarjaE2 (#40) found user CSS forcing animation-timing-function and transition-timing-function to step-start is overridden by ::before and ::after pseudo-elements carrying their own timing functions, and argues disabled users should not have to become programmers to browse without being hurt. Myndex challenges the CSS Color Adjust rule that maps Canvas lightness (L below 33% or above 67%) onto prefers-color-scheme, on the grounds that CIELAB L is not perceptually uniform on self-illuminated displays and the real flip point is higher.

COGA (#737, filed by julierawe) wants haptics added to the note that currently lists font size, icon size, color scheme, magnification and motion, or the list reworded as "include but are not limited to", and asks whether the separate Haptic stimulation adjustable provision in the Animation section is still needed once haptics is covered here. JAWS-test asked the foundational question in 2020 — what does respecting a preference actually oblige an author to do, should pages invert, and what about a page already rendered light-on-dark. mgifford adds two cases nobody answered: dark mode can switch with the time of day so the preference changes mid-session without the user doing anything, and an on-page theme widget should take precedence over the browser preference.

Rather than write separate prose for each level, build a text visibility tool that takes font, size, type, stem and height into account and returns a linear research-based score; point it at any text and pass above X. Proposes a different X for running text, which the eye must read at speed as it passes over the line, than for menus, buttons and other short strings where the user dwells on a word. He did not address the enhanced level as such; on this approach enhanced would be a higher number on the same scale. He offers to have the tool built — but only if someone supplies the research and the interaction effects, which he asked sdw32 for directly.

Because font-size and the labels normal and bold mean substantially different things across families, the APC-RC guidelines set silver and gold levels using reference fonts that a designer matches their own typeface against, a one-time exercise per font. His acuity-reserve table, which does not mention an enhanced level, runs in small steps: 0.18 degrees, an 8.3px x-height or a 16px font at Helvetica's 0.52 ratio, is content minimum at critical size, 0.2 degrees (9.4px x-height, 18px font) is the figure for columns and blocks, and 0.24 degrees (11px x-height, 21.5px font) is preferred body. He also insists a practical standard must not demand that everything in a view hit critical values, since spot text such as a copyright bug and sub-fluent text such as captions exist deliberately to keep the visual hierarchy readable.

He points to EN 301 549, which has a two-level shape: an 8 CSS px x-height as best practice for text that can be zoomed, against a 16 CSS px x-height for text and images of text necessary for functionality that is closed to text enlargement. His glance-readability study — roughly 40 participants, random three- and four-letter words at 300 ms, across Open Sans Light through Extra Bold and APCA 30 to 75 — found Open Sans Extra Bold at APCA 30 outperforming Open Sans Light at APCA 75, so the minimum appropriate font size depends on the interaction of weight and APCA contrast, and a single contrast threshold applied across all weights is not fit for purpose. For weight he proposes Wilkins' pixel-density measure (rasterise the alphabet, crop to the x-height, threshold at RGB 128, count black pixels), giving Open Sans Light 20.2 percent, regular 30.7, semibold 40.0, bold 47.5 and extrabold 56.4 — which would turn the regular-to-semibold Open Sans body-text band, from text he wrote for the non-digital standard interpreting the European Accessibility Act, into a testable range.

patrickhlauke lists the rendering variation that makes nominal size and weight values unreliable to test: OS antialiasing, font fallback and substitution, different cuts of the same typeface with subtly different metrics, and browser rendering that made fonts on macOS visually fatter than on Windows. scottaohara adds that CSS scaling can change the rendered size while the specified font-size stays exactly as authored, so the declared value is not the tested value. TestPartners notes that weight 600 is very common and looks bold while strictly not being bold, so any level that keeps the binary normal/bold split has to say how intermediate values are treated. patrickhlauke supports building GreggVan's tool but treats these as the caveats it must carry.

The enhanced level is currently stricter by banning things — no underlining, no decorative or cursive face. In #266 detlevhfischer called the decorative-or-cursive wording too restrictive as a general rule, and Myndex agreed and called it subjective, ambiguous and arbitrary (the same objection recorded against the minimum); neither commented on underlining, and detlevhfischer did not comment on the alternative. Myndex's counter-proposal reshapes what enhanced would mean: require that a plain accessible font is offered as a fallback and that layout features keep working when the user selects it, ideally through a new prefers-font-family: plain media query. The argument is that a stricter author prohibition is the wrong instrument for a dynamic medium where user personalisation can do the work, especially as these voluntary guidelines are being pressed into law.

In #641, a voice recognition software user points out the asymmetry directly: the minimum permits some underlining and the enhanced requirement does not. Having repeatedly tried to open a link that turned out to be randomly underlined text, they want underlining restricted to links at the minimum level — which would collapse the distinction between the two levels on this point rather than preserve it. They argue underlining is a holdover from handwriting, and that digital text has bold and italic for emphasis while underlining has become the convention for links.

MarcHaunschild opened #191 arguing there is no icon everyone understands, and that an aria-label serves only screen reader users — the sighted majority, people who do not read the Latin alphabet, and speech-input users get nothing. His example is the GitHub editor toolbar, where a large A beside a small A could equally mean resize text; it actually means add header text, and he says he would never have guessed. He reports Germany's BITV-Test once required textual descriptions for icons and dropped the requirement to align with WCAG, which he treats as a regression. alastc drafted the requirement as "a visible text equivalent for icons is available" with icon defined as a non-text representation of a function or discrete piece of information, such as a printer for print or a green tick for complete; MarcHaunschild accepted it and asked for a carve-out, "unless it is essential to be without text", for cases such as a game where guessing the shape is the point.

alastc reported in March 2020 that DavidMacDonald's proposal was worked through in the group and put to a member survey, and that coverage broke down across four scenarios: active and inactive icons, on mouse and on touchscreen. A hover tooltip handles the mouse cases cleanly, but on a touchscreen the user cannot reach the text without activating the control or relying on a flaky double tap, and forcing visible labels into a toolbar destroys the toolbar's purpose. LJWatson cautioned separately against title attributes and the SVG title element becoming the recommended route, since those tooltips are not dismissable; awkawk noted 1.4.13's exception for user-agent-controlled presentation makes them technically permissible, and LJWatson accepted the exemption while maintaining the practice should not be encouraged. detlevhfischer pushed back on the related proposal to extend Label in Name to graphical buttons, asking what a speech-input user would actually say — "click i", "click italics" — and pointing to the existing symbolic-text-characters exception as the right answer.

His #370 argument is that "equivalent" has been so weakly defined that a file name passes in practice: "dog32234.jpg" tells you nothing about breed, setting, activity or the rhetorical reason the image was chosen, and he demonstrates the gap by asking whether readers pictured a French Bulldog on a Hawaiian beach or a Rottweiler on a grassy field. He cites Perkins at under 1 percent of the web compliant, AudioEye at roughly 3 percent and WebAIM at 4 percent, and argues Instagram's billion-plus uploads a day are being pushed toward GenAI descriptions of the form "Might be a man, wearing glasses". He wants equivalence defined against the academic literature on information exchange and extended explicitly to maps, charts, tables, data visualizations and descriptions of people, rather than a title plus a one-sentence overview. In #371 he makes the parallel terminology case: "image" excludes maps, charts and data visualizations in most people's minds, and WCAG should adopt static Audio Description, the term used by the American Council of the Blind, the American Foundation for the Blind, RNIB, the World Blind Union, the American Alliance of Museums and the US National Park Service, over image description, which is largely a computer-science coinage.

patrickhlauke's first reply is a flat correction: "dog32234.jpg" does not pass, it fails 1.1.1 as an inappropriate text alternative. TestPartners argues authors misusing text alternatives is not a loophole — testers frequently do not test the criterion correctly, automated tools cannot yet judge appropriateness, and the root causes are education and authoring platforms that do not help; WCAG 3 cannot and will not fix that. brett-oppegaard called that a defeatist attitude and proposed that WCAG 3 tighten its definitions, add more scaffolding, and create more metrics and benchmarks to close the gap between intent and practice. He adds a newer structural cause: organizations now store images in digital asset management systems with the alt text attached, so the text is written with no knowledge of the context it will be used in, which is why it defaults to a literal description of the image contents. yatil makes the division-of-labour point — W3C defines conformance, laws enforce it, and under the European Accessibility Act member states must stand up agencies with fines behind EN 301 549's reference to WCAG 2.1.

In #272 he asks the group to revisit his proposal "Meaningful images have a text alternative" in place of the current goal that users have equivalent alternatives. His grounds are that decades of evidence show equivalence at scale does not work — he cites WebAIM's finding that nearly a third of images on popular home pages have missing, questionable or repetitive alternative text — and that even where alt text exists there is no agreement on what an equivalent is: ask ten experts and you get ten answers, with far wider spread in the wild. He frames the fix as inter-rater reliability, pointing to slides he presented to the working group three years earlier, and argues a meaningfulness test is both more scalable now and better positioned for changes in technology.

#499 takes the draft sentence on its own terms: "Equivalent text alternatives are available for images that convey content" does not say what the alternative must be equivalent to. He notes that someone carrying WCAG 2 knowledge assumes the intent is the purpose of the image, but read cold the wording points at the content of the image instead — under which "House icon" would be correct and "home" would not.

WCAG's philosophy is that criteria hold simultaneously, so a user who needs magnification must still be protected from seizure triggers; on a phone, 470 CSS px is most of the screen already. WilcoFiers proposes splitting the requirement in two — full-screen content such as video and games, where magnification is not expected, and everything else, where it is. mraccess77 adds that browser zoom is not assistive technology and that authors can read viewport scale.

GreggVan, who drove flashing into WCAG originally, states the intent was never that content be safe at arbitrary zoom — people with low vision also lean toward the screen, and no requirement can survive unbounded magnification. His central argument is cost: a 400% allowance would make the provision more than 10 times harder to pass while still not protecting every user, a rule that draconian would not be adopted by standards and regulatory bodies, and the real solution is display-time detection and prevention tools. alastc opened #631 saying that accounting for zoom removes all sizing assumptions, leaving only contrast and frequency, while acknowledging this misses the low vision plus epilepsy need; asked why GreggVan advised against shrinking the area, he named false positives: failing content that harms nobody, which may be an acceptable trade against seizures but is the main cost. bruce-usab doubts zoom can be factored in, and questions how a full-screen exception could be worded without being too broad to be useful.

GreggVan's reductio — that WCAG could otherwise be replaced by a single site-wide "this site may not be suitable or safe for anyone with a disability" notice — drew a reply from patrickhlauke that the idea was a scoped exemption, not a carte blanche; GreggVan then allowed that content could meet a minimum standard by warning first, provided it is not called accessible. nattarnoff, who experiences these effects, says a warning makes them leave and look for an alternative rather than granting access. mraccess77 notes timestamps on a flashing video still do not deliver the missed information.

In #632 alastc relays Bruce's view that the common YouTuber protocol of a warning plus timestamps addresses the need and satisfies No Flashing through the user-preference note, and expects an exception or applies-when for flashing preceded by a warning. patrickhlauke reads this as an exemption for flashing often outside the author's control, conditional on a warning. In #631 bruce-usab agrees a generic up-front warning is not enough, but argues that a warning at the start and shortly before the flash, in educational content where the flashing is essential and audio description is provided, should be sufficient for WCAG3.

Argued in #23 that open captions are literally pixels of text burned into video frames, so they would fail 1.4.5 Images of Text at AA if they had alt text, and otherwise fail 1.1.1 Non-text Content at A, since no video frame carries alt text. Conceded awkawk's rebuttal on the alt-text point but held the substantive request: open-captioned video should be required to carry a textual transcript in WCAG 3, not only from 1.2.8 upward. Raised the edge case of instructional video with music-only audio, where the captions are effectively carrying video-only time-based media.

Open captions are part of the time-based media, not separate non-text content, so the alternative required at Level A is the alternative for the video as a whole. Captions of either kind are equivalents for audio information, so the Prerecorded Video-Only provision u9000-Nine cited does not apply — video-only content has no audio and therefore no captions. Stated flatly that open captions pass Level A, full stop, and that a transcript for audio information is not required until 1.2.8.

Argues in #23 that without knowing who said what, a story or issue becomes hard to follow, and that this is critical for people with face-blindness — Finnberrys identifies people by voice, so muted or inaccessible audio removes the only cue. Compares captions without speaker identification to reading a playscript with no character names, and cites Teams meetings, where visible names do the work that in-person recognition cannot. Makes the same case for blind users reading captions or a transcript on a braille display.

u9000-Nine notes that identifying speakers by caption position on screen does nothing for someone with face-blindness, since the cue still depends on matching a location to a face. mitchellevan calls the discussion North-America-centric for assuming the identifier is text, pointing to the BBC's subtitle guidance recommending colour to distinguish speakers, a practice also common in continental Europe — while acknowledging colour identification may itself fail Use of Color. Neither rejects the need; both points bear on which mechanism would satisfy it, and mitchellevan asks for more international context.

On whether advertising and promotional video should carry less weight than primary content, mraccess77 points out that inaccessible video causes clear discrimination in areas such as fair housing and healthcare, and draws the parallel to audio description, once dismissed as unnecessary for entertainment until entertainment was recognised as a right too. mitchellevan agrees on equal weight: user needs and technical feasibility are the same, "promotional" resists definition, and regulations such as the US Air Carrier Access Act already carve out advertising where a jurisdiction wants that. Prioritisation should sit in regulation, not be baked into a technical standard.

InfoGapBuster, writing as a Deaf person in #325, argues auto-generated subtitles may be inaccurate or fail to convey tone and nuance, and that WCAG 2.0 putting sign language at AAA led to limited implementation. Cites 250,000 to 500,000 primary ASL users in the US per Gallaudet, roughly 70 million Deaf people globally per the World Federation of the Deaf, about 60,000 JSL users in Japan, and 90 to 97 percent of Deaf children born to hearing parents with the resulting risk of language deprivation. Wants sign language translation — prepared in advance, distinct from live interpretation — named as a distinct outcome, arguing that requiring it would generate demand, grow the interpreter pool and accumulate training data. md84419 goes further, calling for a sign language alternative to website text and citing the BSL Act 2022, the Equality Act 2010, the Irish Sign Language Act 2017, the Korean Sign Language Act 2016 and the New Zealand Sign Language Act 2006 as evidence that language-based discrimination is already legally constrained.

alastc opens #632 as a placeholder to make sure the updated flashing requirements work with the warning requirement, quoting Bruce's comment that YouTubers commonly warn about flashing and give time stamps, a protocol Bruce considers sufficient for the disability-related need and believes satisfies No Flashing via the note on accessibility-supported user preferences, though it takes a bit of rationalization. Bruce asks that the note, or the easily avoidable idea, be made explicit. alastc suggests an exception or applies-when clause will probably be needed. patrickhlauke reads the idea as exempting situations often outside the author's control as long as there is at least a warning first, but says the exemption must exist in the first place and is not a carte blanche.

GreggVan objects that counting a warning amounts to saying something is accessible if users are warned not to use it; warnings are good but should not count as passing that content. He later allows that the group can say a site meets its minimum standard if it warns first, or exclude content through an exception, as long as it is clear the content is not accessible. nattarnoff, who uses motion trigger warnings in presentations and is affected by such effects, says a warning should exist but is not sufficient: faced with one, nattarnoff leaves and looks for an alternative, and closing one's eyes for a few seconds usually means missing key content.

sydneycolemanfromgoogle's #541 says the phrase trigger warning has a broader meaning and could be read as belonging to the Control possible harm - Triggers area, and asks for a more specific name or a different phrase. julierawe's #736, filed for the COGA Task Force, notes that trigger warnings usually concern emotional health, which makes the provision confusing when its note defines triggers as flashing, motion lasting more than 5 seconds, and pseudo-motion; it recommends renaming it "Motion warnings available".

In #542, supports the effort but says it requires a specific list of common triggers to be tagged; leaving the determination to products would produce wildly inconsistent results, and subjective guidelines could supplement such a list but not replace it.

SuzanneKTaylor's #88 argues content can create a mood without containing any item identifiable as a trigger, and proposes that information about the mood content is likely to encourage be available or user-selectable, aimed at long-form content such as a movie, an ebook or a VR experience. medeaoblongata sees a related gap for connotative aspects of content, as distinct from denotative or purely decorative ones, where flagging a connotation can be more useful than a description.

detlevhfischer says mood depends on the user and context rather than being a property of content, that exposing annotations would add to cognitive load for many users, and that he does not see how it could become a general measurable outcome. ericwbailey says it would be impossible to quantify, before even considering cultural differences. patrickhlauke dreads auditors having to check this kind of meta information when judging conformance.

SuzanneKTaylor's #89 proposes that interwoven storylines be programmatically distinguishable or selectable, so some subtle triggers can be avoided by watching or skipping one full story. GreggVan replies that no content is free of triggers for everyone and that AI-based AT that detects and redacts per individual is the better route. SuzanneKTaylor agrees AT may handle these outcomes, with WCAG concerned with whether AT has the access it needs, but warns that a personal trigger profile could itself be triggering or harmful if leaked, so outcomes may need to stay at simple, common triggers for now.

patrickhlauke opened #190 arguing that although SVG contains real text elements and so passes the normative definition of images of text, no user agent lets a user change the font, size or colour of that text, which is the whole point of the criterion. alastc agrees the intent is not met and proposes a split: if the text's size, position and colour must be relative to its surroundings, as in a graph or infographic, it meets the "particular visual effect" carve-out; otherwise it fails. He puts the colour half at user agents and treats the font and spacing half as inherent to SVG's purpose.

Walks the criterion property by property and finds browser zoom, font size, font family, letter spacing and word spacing all work in SVG, with line-height and paragraph spacing the only genuine gaps. Argues those were not required until WCAG 2.1's 1.4.12, which only forbids preventing adaptation rather than requiring the author to offer it, so SVG text should not be held to a higher bar. Later narrows this after testing goodwitch's examples: he would only pass an SVG that inherits the document's colours, because adjusting fill values per graphic demands CSS expertise and time most users do not have.

Built three CodePen examples and concluded that SVG with text passes, SVG with path-drawn text fails, and an svg file loaded via img fails. Pushes back on JAWS-test that High Contrast Mode is not named in the normative text and the criterion nowhere says customisation must be easy, so on a strict normative reading this has to pass. Asks AGWG to make a ruling so the industry is consistent, and suggests the real fix belongs in a WCAG 2.x release or Silver.

Reports in #202 that the text-to-speech subgroup could find nothing specific to text-to-speech devices that a screen reader would not also cover, and proposes moving Detectable text out of Clear meaning into the Text-to-speech section to replace the Text-to-speech supported requirement. Also asks whether "text-to-speech" names the technology or the capability, suggesting a rename such as "Text as speech" if the latter, and where user-agent and TTS developer guidance would live in WCAG 3. No one has replied.

In #537, calls the provision a step in the right direction that stops short: text that is programmatically determinable but cannot be selected breaks select-to-speak. Also flags possible redundancy with the copying-supported part of "Avoid exclusionary cognitive tasks" and suggests the two may be better combined or regrouped. Unanswered.

WCAG recommends captions but specifies nothing about whether the result is readable or usable. Proposes WCAG 3 adopt the Association of National Advertisers captioning standards, which are the basis for the FCC's television captioning rules and the National Park Service captioning guidelines. Filed as #119 in October 2024 and has drawn no reply from anyone in the thread.

PoornimaSubramanian's case in #234 is that closed captions give the user control over when to turn them on or off, and can be customised by the editor for font face, size and position, so a rating should turn on the presence and accuracy of closed captioning, with a Rating 0 for informational or essential video carrying no metadata. WilcoFiers's opening question in #23 pushes further, asking whether open captions should be disallowed on new video material at all, and noting closed captions may be routable to a braille display. Neither has been answered in the threads.

Open captions are part of the time-based media, so they need no alternative text of their own; the alternative required at Level A is for the video. The video would fail 1.1.1 only if there were no text alternative identifying the video itself, and a transcript for audio information is not required until 1.2.8. Also corrects the video-only framing: captions are equivalents for audio, so video-only content has on-screen text, not captions.

Opened by arguing open captions are literally images of text and so fail 1.4.5 at AA, or 1.1.1 at A if they lack alt text, since video frames have no alt text mechanism. Conceded awkawk's reading but held the underlying proposal: because captions are explicitly an alternative for audio, WCAG 3 should require open-captioned video to also have a text transcript. Raised as an edge case open-captioned instructional video whose only audio is royalty-free music, where the captioned information is effectively video-only time-based media.

mraccess77 argues exemptions are a regulator's job, since inaccessible video causes clear discrimination in areas such as fair housing and healthcare, and cites the shift on audio description for entertainment as precedent that entertainment is a right too. mitchellevan agrees on same weight, on the grounds that user needs and technical feasibility are the same, that "promotional" is hard to define, and that regulations such as the US Air Carrier Access Act already exempt advertising. Nobody argued the other side.

Understanding a conversation often depends on who said what, and without the who a story or issue becomes hard to follow — like reading a playscript with no characters identified. Speaks from experience of face-blindness: usually identifies people by voice, so on a muted device or with a hearing impairment, following a conversation between people who look similar is very difficult. Compares captions carrying names to a Teams meeting, where every participant's name is visible, versus an in-person one. Extends the same argument to blind users reading captions or a transcript via braille.

Identifying a speaker by where the caption is placed on screen does not help someone with face-blindness. Finnberrys replied that having the captions identify speakers with a name helps in knowing who is speaking, comparing it to names being visible in a Teams meeting.

The discussion is North-America-centric in assuming the identifier is text. The BBC recommends colours to distinguish speakers, and the practice is common in continental Europe. Explicitly does not claim colour is better than text, or even that it is accessible — flags that it might fail Use of Color — but argues the provision needs international context before it settles on a mechanism.

In #512: in a live meeting or its recording, several people sharing a room are grouped as a room rather than identified individually, so the provision should say it is limited to speakers who are systematically identifiable. Second case is a video with one speaker who introduces themselves at the start, where announcing the speaker every time is repetitive. Concludes the provision needs more work or should remain supplemental for now.

In #748: the provision applies only when there are multiple speakers in the video, which should be generalised to media so it covers audio without video, video without audio, and video with audio.

In #472: each note under the foundational wording — full name then part of name, hidden identity as part of narrative structure, recognisable position within the context of use — needs a concrete example. The only example the provision carries is the Maya Angelou to Angelou shortening.

The case in #23 is argued mainly from captions and face-blindness, but explicitly extends to a blind person reaching the material as a transcript or captions through braille. Without speaker identification, reading it is like reading a playscript with no characters identified. This is the only point in the record that speaks to transcripts specifically, and nobody contested it; the fuller argument is under Speakers identified in captions.

u9000-Nine's repeated proposal in #23 is that open-captioned video should be required in WCAG 3 to carry a text transcript as well, because "captions are explicitly an alternative for audio". The points that closed captions may be customisable and routable to a braille display come from WilcoFiers's opening questions in #23, not from u9000-Nine. This is about whether a transcript exists at all rather than about identifying speakers inside one. awkawk acknowledged it as a clear proposal without endorsing it, having pushed back on the 1.1.1 and 1.4.5 reasoning behind it; that exchange is written up under Captions adjustable.

MakotoUeki (#472) wants a concrete example for each of the three notes — full name then part of name, hidden identity as narrative structure, recognisable position within the context of use. sydneycolemanfromgoogle (#512) wants the provision limited to systematically identifiable speakers, citing shared-room meeting recordings and a lone self-introducing speaker, and suggests it stay supplemental. ashleemboyer (#748) wants "video" generalised to "media", which lands hardest here, since an audio-only recording's transcript is frequently its only alternative. None of the three has had a reply, and none distinguishes transcripts from captions.

Argues the discussion is North-America-centric in treating text as the identifier, pointing to the BBC's recommendation of colours to distinguish speakers and its common use in continental Europe, while noting colour identification might itself fail Use of Color. He raised this against the captions discussion; nobody has addressed what it means for a provision written once to cover both captions and plain-text transcripts.

The draft SC in #193 reads: when a user interface component visibly indicates its states, these states are visually distinct and correspond to the programmatic states. The wording deliberately dodges the question the mobile accessibility task force could not settle — how much visual difference counts, since changing one pixel in a graphic is technically a difference — and instead leans on 1.4.11 to handle the 3:1 contrast of the salient part. The value he claims for it is the correspondence itself: catching a state change that is missing, reversed, or otherwise out of sync.

Mixing programmatic state into a visual SC opens a loophole: a control with no programmatic state fails 4.1.2, but would nominally pass this one because there is nothing to disagree with. He proposed replacing that clause with wording along the lines of accurately represents the current state of the component, and also questioned whether visually distinct is firm enough for normative language, foreseeing the same problems as visible focus indication. detlevhfischer accepted the substitution as an improvement.

#197 starts from the observation that disabled interface elements work badly for people with low vision and suggests that, rather than only exempting them from 1.4.3, a better way might be a disabled icon; DavidMacDonald proposes at least 3:1 contrast OR an icon marking the element disabled. bkimmel seconds the problem, particularly where disabled controls are used to advertise the potential of an interaction — fill these fields in and you can submit — which he calls a huge safe harbour for things that cut against the Perceivable goal. He is not convinced an icon specifically is the answer.

He would far rather see some form of minimum contrast apply, to solve readability, than require an icon — WCAG cannot start demanding icons everywhere without dictating visual design. His preferred shape is a more general intent of indicating that something is disabled, and he flags a crossover with how user agents themselves render disabled state.

Reviewing #197 against the current draft, adampage notes disabled elements fall outside the definition of interactive element — an element that responds to user input and has a distinct programmatically determinable name — so the neighbouring Interactive elements distinguishable provision does not reach them. They appear instead to match non-interactive element (does not respond to user input and does not include sub-parts), but are absent from that definition's examples and notes, so the intent is unclear. He suggests broadening the term or introducing a new one for elements that exist to be interactive even when conditionally disabled or read-only, and points at the Disabled controls explained provision and w3c/wcag#5053 as related.

#207 proposes reorganising all the colour and contrast outcomes on vision-science lines: luminance carries high spatial frequency information and is what reading depends on, hue matters for object recognition and colour-coded non-text material, and spatial frequency — font weight, size, letter and line spacing, padding, glyph design — is the critical factor in readability. That yields two guidelines, one for not relying on colour alone plus non-text contrast, one for luminance contrast in readable content, with non-text use cases classified as Semantic, Symbolic, DataViz and Container. He also argues specific legacy numbers are unsupported: the 80-characters-per-line figure traces to IBM equipment economics rather than research (Bringhurst's 66 characters, or a 50 to 70 range, offered as informative), and a 1.5 line-height rule is near meaningless in CSS because the x-height to font-size ratio varies by 50 percent or more between families.

Disturbing Content and Triggers only catch acute, identifiable items, but content can create a mood with nothing in it that flags as a trigger. SuzanneKTaylor's proposed outcome (#88) is that information about the mood content is likely to encourage is available or can be changed or selected by the user, aimed at long-form content — a movie, a television show, an ebook, a VR experience — where a user managing anxiety would benefit from knowing before committing. medeaoblongata frames the same gap as connotative content, distinct from denotative and from purely decorative, and notes that a detailed description can kill the effect it describes, since the sinister or the erotic is often about what goes unmentioned, so flagging a connotation in lieu of a description has value.

detlevhfischer's objection is that mood is not a property of content but depends on the user and on surrounding context, and that annotation would have to be exposed both visually and programmatically for equity, adding more material to the sea of content and increasing cognitive load for people it does not help — he does not see how this becomes a general measurable outcome. ericwbailey says it would be impossible to quantify before cultural variation is even factored in. patrickhlauke's concern is downstream: he dreads auditors having to check this kind of meta-information when judging conformance.

Issue #89 proposes that individual storylines be programmatically distinguishable, or that users can choose storylines. The argument is that hiding individual items leaves the surrounding context intact and so does not actually protect the user, while interwoven plots also tax memory and the ability to distinguish characters, locations and times. Her worked example is a video cutting between three people's stories in ten-minute and then five-minute blocks: being able to watch or skip one full story handles some subtle triggers by a simple mechanism rather than by content judgement.

GreggVan argues no content can be written that triggers nobody — depending on personal history, a grove of trees could be a trigger — and that the group risks a never-ending discussion of what counts, so an AI filter that detects and redacts per the individual is the better place for it. SuzanneKTaylor partly agrees and extends it: if these outcomes live in AT, WCAG's remaining concern is whether that AT has the access it needs to pre-screen, which is a question about whether it can traverse a whole movie or gets stopped at the first ad. She adds that she personally thinks new AT is needed for many of the outcomes.

The counter to GreggVan's AI filter is that the profile it needs is itself hazardous: asking a user to enumerate their triggers could be more triggering than the content, and a leaked profile could be used for serious harm — her example is a politician whose debate opponents obtain a copy. Her conclusion is that simple and common triggers, of the do-not-show-spiders-in-this-game kind, are addressable now, and outcomes may have to stay at that basic level until more is known.

2.4.6 says headings must describe the purpose or topic; it does not say only where a specific topic exists, nor that a heading may merely label a section (#170). A chapter heading might set a mood or theme, or introduce levity or absurdity, and the examples in the Understanding document reinforce the bias by showing content that breaks down neatly by topic. He has always ignored the SC for publishing, but calls it troubling to tell people to ignore a criterion because it does not make sense outside one context, especially as the part about labels describing the purpose of inputs is genuinely useful.

scottaohara reads a chapter title as naming the chapter you are about to read rather than summarising it, which is itself a useful title, and says he would be surprised to see anyone report this. patrickhlauke agrees more bluntly: determining what is and is not descriptive enough is completely wooly and subjective, so there is plenty of wiggle room, you can handwave fiction, and if someone insists it fails, let a judge or lawyer work it out. He still presses the hard case — a chapter titled A peaceful morning over text describing atrocities in a war-torn country is deliberately non-descriptive, even says the opposite of the content, and appears to contravene the normative requirement, while the Understanding quietly pivots from descriptive to merely providing a cue or landmark. bruce-usab's counter is that headings must describe topic or purpose rather than be descriptive, and that A peaceful morning memorably identifies the chapter's main substance.

His recollection is that fiction chapter titles were among the use cases considered when 2.4.6 was phrased. The Understanding document states that a word, or even a single character, may suffice if it provides an appropriate cue to finding and navigating content — so a cryptic but deliberately chosen chapter title clears the bar, and esoteric novel headings are both descriptive and well suited to their purpose. He concedes a plain reading has the implication mattgarrish describes and calls it a defect that the nuance lives only in Understanding, adding that in publishing the SC is always satisfied because a real-world failure is probably impossible to find, which is not true of the web, where pages with seemingly random headings exist.

JAWS-test opposes rewriting the SC because any relaxation weakens it for labels, and form labels should be meaningful — not ironic, not a single character — even where headings can be held to a lower bar. His preference is an Understanding addition covering fiction now, with WCAG 3 treating headings and labels as separate requirements. mattgarrish accepts this is the cost of combining the two in one criterion. Two replacement phrasings were floated and neither survived: mattgarrish's Headings and labels establish context, which he argued covers chapter numbers that convey no topic but do tell you how far into a book you are, and bruce-usab's Headings and labels provide descriptive identification of the topic or purpose, which mattgarrish rejected as a wordier way of saying describes that still assumes a topic exists.

A separate strand (#80), filed by rachaelbradley on behalf of a public-agwg-comments email from a commenter who describes themselves as a screen reader user and accessibility tester, argues that sections being visually and programmatically distinguishable is not enough and that clearly labelled semantic landmarks separating distinct page content should be required — header, main navigation, breadcrumb navigation, main content, aside, footer. The case made is practical: landmarks are well supported in browsers, easy to implement in HTML5, ARIA and JavaScript, deliver real benefit to AT users, and are easy to test. Nobody has replied.

#477 asks for meaningful blocks of content to be defined, quoting GreggVan's objection that the phrase is used to mean a section, a heading and even a paragraph inside a section, and that one term cannot carry three meanings — his test case is whether posting a letter online obliges you to label its introduction and its sections. It also asks that the exception, where a label is not needed to understand the purpose of the content within the context of use, be bounded, since as written it can be invoked too broadly.

In #370, argues alt text is a legacy of early image-loading problems rather than a disability-studies concept, and that in practice a filename like "dog32234.jpg" is treated as compliance. Cites Perkins at under 1 percent of the web compliant, AudioEye at around 3 percent and WebAIM's Million at 4 percent to argue the failure is systemic rather than incidental. Wants "equivalent" defined against the information-exchange literature and extended with guidance for describing people, maps, tables, charts and data visualisations, not just a title plus a one-sentence overview. Points at Instagram, where alt text is buried behind a hidden process and GenAI supplies descriptions like "Might be a man, wearing glasses".

patrickhlauke's opening reply is flat: "dog32234.jpg" would fail 1.1.1, so it is not legally compliant in any sense. TestPartners attributes the observed state to testers not testing the criterion correctly, automated tools being unable to judge appropriateness, and authoring platforms that do not help — a lack of education, not a defect in the wording, and something WCAG 3 cannot fix. yatil adds the structural point that W3C defines conformance and does not enforce it; enforcement runs through civil rights litigation and, in the EU, through the European Accessibility Act's reference to WCAG 2.1 via EN 301 549, with national agencies and fines that only began operating this year.

TestPartners identifies a newer failure mode: organisations now store images in a DAM with the text alternative attached to the asset, so the alternative is authored with no knowledge of the context it will appear in, and ends up an invariably literal description of image contents that may be appropriate in one placement and wrong in another. brett-oppegaard accepts the point, proposes that descriptions be crafted per use and logged so a forensic recontextualisation is possible, and concedes this would require a major shift in archiving practice. Both treat it as a real problem; neither claims it is the central one.

In #611, argues the draft never says which formats are usable for which medium and that the media alternative definition adds nothing. Offers an absurd-but-passing case: video-only content with an empty closed caption track satisfies the requirement as written. Proposes splitting the test procedure into separate procedures for audio-only, video-only and audio-video content, each ending in a check that the alternative is equivalent to the meaningful information in the media.

Opened #27 using WCAG 2.1 SC 2.3.3 as the cautionary example: it sits at AAA, it permits essential smooth animation, and it permits any smooth animation so long as some way to disable it exists, without requiring that the site-specific control be discoverable or that prefers-reduced-motion be honoured. Worries the essential exception will be stretched to cover any move or transition someone decided to make smooth. Notes many sites impose their own smooth scrolling regardless of prefers-reduced-motion or of browser settings to disable animation and autoplay, and that JavaScript-driven animation, including GitHub's own sticky headers, makes it harder still for users to protect themselves.

The COGA Task Force filed #739 asking that pseudo-motion be defined with examples - parallax scrolling, sharp color changes, dynamically updating content, zoom effects, diagonal lines in a background, optical illusions, stereographic art - and that "No pseudo-motion" be split into its own provision, because the current wording can be misread as "Content does not include pseudo-motion…lasting longer than 5 seconds"; the request names both No visual motion provisions, not this variant specifically. julierawe later added gamma oscillation images and sliced images. rachaelbradley offered the decoy font experiment as a candidate example and mraccess77 confirmed first-hand that those fonts appear blurry and give them a headache. In October 2026, Charles Hall drafted a standalone pseudo-motion provision (currently supplemental, with research indicating harm comparable to actual motion) and focusing on a mechanism to prevent, turn off, or hide pseudo-motion.

alastc opened #629 on the draft note allowing content to be considered as avoiding flashing when an accessibility-supported preference to prevent flashing is respected, doubting any such method is accessibility supported today and asking whether it should be relied on even if one were. julierawe, quoted in the body, calls the method dangerous and asks what happens when someone uses another person's device without having set the preference first. alastc flags in the body and again in June 2026 that the same question lands on the animation and reduced-motion requirements, which is how it reaches this provision.

patrickhlauke asks whether there should be a mandated warning before content containing potential flashing, with enough time for the user to abort or back out; alastc answers that a separate flash and motion warning requirement already exists in the working document. nattarnoff asks whether warning is an authoring duty at all or belongs to browsers detecting content type against the user's preferences, is unsure browsers could feasibly do it, but observes that we know what happens when it is left to the people who build sites, and argues this requirement straddles the bottom-up and audit-and-remediate approaches.

Responding to the opening questions in #19, asks whether there is a requirement for headings to be visually distinct in the first place, since content that is indistinct for every reader alike looks like a design quality issue rather than an accessibility one. On the font versus typeface point he replies that it is fine as long as things are programmatically different. He also questions the "sufficient semantics" framing, reading it as sufficient meaning and suggesting, with the hedge "(I don’t think)", that WCAG cannot require authors who write meaningless headings to rewrite them, while asking whether something different was meant.

Argues visual hierarchy is squarely an accessibility issue for COGA among others, and that it is also a contrast issue: the amount of padding around a text block, line spacing and letter spacing all change perceived contrast, and this is most critical for blocks of body text. Contends the primary driver of perceived contrast is spatial, chiefly rasterized font weight, because weight sets the spatial frequency the contrast sensitivity function responds to. Cites Lovie-Kitchin and colleagues for contrast reserve figures keyed to use case, roughly 20 times the JND threshold for article body text down to 3 times for non-fluent spot reading.

Wants the methods currently used to separate blocks and headings surveyed first, so a new requirement does not accidentally outlaw one that works, and notes that distinctions are frequently used in combination rather than singly. Lists boldness, font size, typeface, indentation, underlines and overlines, italicization, small caps, script, color, textual or iconographic markers and text alignment. Refines Myndex's three-way split into four groups: spatial, visual text attributes, content and external indicators.

Opened #476 asking for a re-evaluation of whether the visual and programmatic aspects of meaningful content blocks should be separate requirements, because one can be satisfied while the other is not. Also asks for "sufficient surrounding space" to be defined, and for exceptions to be considered where a particular layout choice means spacing may not be required.

Points from GreggVan that giacomo-petri listed in #476 for review, without adding his own view on them: the draft requires information to be programmatically determinable that is not visually determinable, which reverses the usual direction, and the wording needs to say that where content appears as a block carrying semantic meaning, that block also has to be programmatically determinable. On spacing, paragraphs often have no more space between them than between the lines inside them, yet they are meaningful blocks, so the reductio is whether every document must now add space between every paragraph, and whether the answer is one pixel, two, or three.

Questions whether there is a requirement for headings to be visually distinct at all, since headings that are not distinct for anyone are not obviously an accessibility question. Accepts differentiating font from typeface as long as the result is programmatically different. Pushes back on the suggestion that sufficient semantics on headings matters more than visual presentation, reading "sufficient semantics" as "sufficient meaning" and suggesting, with the hedge "(I don’t think)", that WCAG cannot require authors who write meaningless headings to rewrite them, while asking whether WilcoFiers meant something different.

Holds that content structure for a good visual hierarchy matters for COGA among others, and that it is simultaneously a contrast question: padding around a heading, leading and letter spacing all change perceived contrast, as does font weight. Argues weight is the most critical spatial quality because it sets the spatial frequency that drives contrast sensitivity, illustrated with same-color samples at different weights placed on the contrast sensitivity curve. Also warns that the CSS font-size metric is close to futile as an absolute, since size and weight vary massively between families.

Wants existing sufficiently distinct methods catalogued so a requirement does not accidentally remove one, and stresses that combinations of distinctions matter. Proposes four groups rather than Myndex's three: spatial, visual text attributes, content, and external indicators, with capitalization, writing system, sentence type and person placed under content. Argues writing system in particular belongs with content, since writing in sitelen pona carries semantics and nuance that Latin script or speech does not.

Filed #81 on behalf of a commenter who wrote to public-agwg-comments; the submitted comment asks for an outcome stating that section heading levels be semantically nested so they form a hierarchical outline of the content, and that there be only one h1 per page, reserved for introducing the main content or topic and matching or closely resembling the page title. No one has replied since May 2024.

Opened #478 asking that "higher" and "lower" be replaced when referring to heading levels, since which direction each word points is ambiguous. Also wants "meaningful block of content" clearly defined and exceptions specified, recognising that paragraphs, letters and emails may not require headings, while insisting any exception be explicit enough that it cannot be used as a loophole. Notes both items may resolve from a single consistent definition.

LaZay opens #161 asking that font selection join the other user-adjustable properties in 1.4.8, noting publishers still ship serif paper fonts in digital products where they blur on screen, and that any offered families have to exist on the user's machine — a harder implementation problem than other CSS overrides. LaurenceZaysser makes the same case in #340 as a gap rather than an enhancement: 1.4.4 Resize Text has no font-family equivalent, browsers and ebook reading systems already do this, and WCAG 2.2 is therefore not the full EAA cover it is claimed to be, since Annex I requires fonts of suitable shape. Proposes a new SC 1.4.14 Change font family with a sufficient technique naming OpenDyslexic.

Argues in #245 that a meaningful, testable normative standard covering all font use cases is out of reach, though blocks of body text might be a candidate. The reason is that line-height, letter-spacing, font-weight and font-size are all relative to decisions the font designer made, so two faces set at 16px and weight 400 rasterise at different real sizes and weights. Proposes CSS-level fixes — a property to set x-height directly, already filed with the CSSWG, and line-height expressed against x-height — and gives concrete targets: critical size is an x-height at least twice measured acuity height, lowercase aspect ratio under 1.5:1, baselines about 2.5 x-heights apart. Notes a century of research has produced little consensus beyond "blackletter fonts are hard to read".

In #245 in 2022, before the OpenDyslexic proposals in #161 and #340 were filed, argues that fonts like OpenDyslexic and Dyslexie are not actually useful, because they assume dyslexia is a visual problem when it is language-specific. Cites Marinus, Mostard et al., where increasing letter spacing on plain Arial produced the same benefit as Dyslexie, implying the gain comes from reduced crowding rather than glyph shape. Adds that dyslexia is almost unheard of in Korean, which is a clear language, so glyph-level remedies do not generalise across writing systems — of which there are at least 40 common ones.

If CSS is not expressive enough for authors to declare these properties or for tools to query them from a rendered page, and font choice is effectively unlimited, a tester would have to run the numbers against every font an author picked — complicated further by user agents and operating systems shipping their own slight variants of nominally identical fonts and doing substitutions. Pushes chaals directly: if the user agent does not supply an accessible font, does the site then fail in that user agent? Draws the line at information, advice and best practice being fine, while mandatory requirements built on the same evidence is where it gets interesting.

Where the user agent supplies the font, the requirement belongs on the user agent to offer accessible fonts. Research on this has existed for a long time, so publishing information about which fonts are more accessible — and to whom, and when — should not be beyond the group. Adds the author-side corollary: if you choose fonts and want accessible content, logic says you check whether the fonts you chose achieve that.

In #413, reads G183's "if there are not a large number of links" caveat as an implicit allowance for a different treatment in high link-density content such as wikis and glossaries. Argues G182's non-underlined alternatives — blue bold, red italic — are not reliably read as links, because user expectation is anchored to underlines. Proposes a Method under the adjustable text style guideline using text-decoration-style: dotted, with a demo file attached, to keep links perceivable while cutting visual clutter.

Live audio+video requires captions at AA (SC 1.2.4) while live audio-only sits at AAA (SC 1.2.9), a split made when internet-radio-style audio streams were common and live video was technically onerous. Twitch, let's plays and live webinars have reversed that, and captioning either is equally hard. Taken to its conclusion, an author doing a live audio-only vlog is off the hook, but turning the camera on to show their face makes them fail. Raised in #189 in 2019 and carried forward with no reply on the substance.

Auto-generated subtitles may be inaccurate and fail to carry tone and nuance, so captions alone do not deliver equitable access for Deaf people whose first language is signed (#325). Proposes graduated conformance: auto-generated or basic captions at Bronze, accurate descriptive captions plus context-appropriate sign language at Silver, and culturally appropriate sign language with multilingual caption options at Gold. Wants minimum quality guidance covering accuracy, speaker identification, emotional tone and cultural context.

Notes that Gold is likely achievable without doing everything listed at that level, and that the working group has not finalised what Bronze, Silver or Gold mean. Nothing definitive can be said about which tier anything lands in yet. Unrebutted, and the tiering discussion continued regardless.

Points to "Captions are available for all live audio content" and suggests that it can absorb some other requirements about captions for live video, merging them (#461). Filed as a short review note in December 2025 with no responses.

Argues WCAG 2.0 put sign language at AAA and this led to limited implementation; writing as a Deaf person, InfoGapBuster reports that when sign language is not a required criterion organisations default to captions alone (#325). Wants "Provision of videos with sign language translation" defined as a distinct Outcome, and draws a line the draft does not: interpretation is real-time signing for live contexts, translation is prepared in advance with attention to clarity and accuracy, and translation is what prerecorded content intended for repeated viewing by a wide audience should get. Answers the obvious objection about scarce qualified interpreters and translators by arguing that requiring it generates demand, expands the pool, and accumulates data that could train future AI translation.

Agrees with the whole proposal but wants Gold treated as a genuine aspirational benchmark, and calls for a supplemental requirement that sign language users have access to a sign language alternative for website text, not only for video. Grounds it in the same rationale InfoGapBuster gave, that millions rely on sign language as their first, preferred or only accessible language, and in anti-discrimination law: the UDHR, ICCPR, EU Charter and American Convention, plus the ADA's auxiliary-aids duty, the BSL Act 2022 and BSL (Scotland) Act 2015, Ireland's Irish Sign Language Act 2017, South Korea's Korean Sign Language Act 2016, New Zealand's NZSL Act 2006, and Filipino Sign Language mandates. Adds ISO 24495-1:2023, ISO/IEC 29184:2020, GDPR Article 12(1) and EU AI Act Articles 14 and 50 on information in an intelligible, preferred-language form.

The only note of caution in the thread. Gold is likely achievable without meeting everything listed at that level, and the working group has not finalised what any of Bronze, Silver or Gold mean, so nothing definitive can be said about placing sign language in one. Neither participant contested this, and both continued proposing level assignments.

Questions whether "We provide sign language interpretation for all live audio content" should be a supplemental requirement rather than an assertion (#471). The issue states no reasoning beyond the question itself. Filed in December 2025 with no body beyond the question, no comments, and closed in June 2026.

In #325, distinguishes sign language interpretation — real-time signing used in live contexts — from translation prepared in advance, and argues the draft does not separate them. Places live interpretation at Silver where appropriate, and at Gold as high-quality interpretation with cultural and linguistic appropriateness alongside multilingual captions. Writing as a Deaf person, argues that anything short of a defined requirement leaves organisations relying on captions alone, and that requiring it is what builds the currently limited pool of qualified interpreters.

Supports the proposal and pushes past it, calling for a supplemental requirement that sign language users have a signed alternative for website text. Cites jurisdictions that already require sign language interpreting or translation in some public or official contexts: the ADA's auxiliary aids and services duty for US public entities, the UK's BSL Act 2022, BSL (Scotland) Act 2015 and Equality Act 2010, Ireland's Irish Sign Language Act 2017, South Korea's Korean Sign Language Act 2016, New Zealand's NZSL Act 2006, and Filipino Sign Language mandates — alongside language-discrimination treaties, framing information in a preferred language as a reasonable accommodation. Its first-listed rationale is the same as InfoGapBuster's: millions rely on sign language as their first, preferred or only accessible language.

Gold is probably achievable without meeting everything at that level, and none of Bronze, Silver or Gold has been finalised, so no definitive statement about placing sign language in a level is possible yet. Unrebutted; the thread continued assigning levels anyway.

cawa-93 opens #171 with white text on black at a 21:1 ratio, which passes 1.4.6 Contrast (Enhanced) at AAA and is, in their words, absolutely not readable, and proposes a maximum alongside the minimum. NathanInnes offers Twitter's branding revamp as a case in point: it passed beyond the standard and a lot of users found it difficult to read and straining on the eyes.

JAWS-test finds high-contrast text readable in itself, accepts that some people struggle with it, and argues the fix is for colour adaptation to user needs to work well and for WCAG to support that adaptability via custom styles, Windows High Contrast Mode and similar. mraccess77 says a contrast maximum would negatively affect them personally while acknowledging others need low contrast, and concedes specific bad combinations exist — small white text on black being one — before asking whether a better calculation than current contrast could isolate those cases, pointing at Myndex's work.

Myndex's objection in #171 is that WCAG 2 contrast math is not perceptually accurate — it already overstates minimum contrast for dark colours — so building a cap on it would produce more unreadable pages, not fewer, and entrench the misunderstanding of how contrast and readability work. Reframes the problem as excess luminance rather than excess ratio: users crank screen brightness to cope with all the low-contrast content in the wild, then get blasted by a site with good contrast. Also notes the OP's own example is too small and too crowded to be evidence. bruce-usab agrees white on black is a common barrier but cannot see how to address it in WCAG 2.x even at AAA, since the same rule would flag plain black-on-white body text, and points to APCA as the WCAG 3 route.

The 2023 status update separates the cases: no maximum contrast in light mode, only a maximum luminance, which is a user display control rather than an author one, with paper-emulation best practice of keeping body-text background at about 85 percent of the adaptation state. Dark mode is different — excessively bright text on dark backgrounds causes halation and glare — and names interim experimental values under study of Lc -90 maximum for body text and Lc -85 for larger text, using APCA 0.0.98G4g. Adds that there is room for at least two dark schemes, day and night, and that daltonised, photophobia and Meares-Irlen schemes will likely need their own maxima.

Reports from a calibrated setup — displays at 150 cd/m2 white luminance, room illuminance around 100 lx, IPS LCD at roughly 1000:1 static contrast — that black on white is comfortable while white on black remains practically unreadable, partly from halation due to astigmatism. Finds Lc -90 uncomfortable and would want something nearer Lc -50 for light-on-dark. Also warns the fix cuts both ways: in a properly calibrated environment, an author lowering contrast for dark text on light backgrounds reduces readability, comparing blue on brown to printing on kraft paper rather than white.

emanser869's #178 proposes adding to 1.4.8 that foreground and background colours can be adjusted by the user to apply uniformity of contrast.

utkudyn-a11y's #618 asks that captions carry at least 4.5:1 between caption text and its background as a core requirement, in addition to the supplemental captions-adjustable requirement, because caption legibility directly affects partially sighted and low-vision users.

Calls "Non-decorative images are detectable" painfully vague and asks the specific questions the text cannot answer: detectable to whom, what counts as detectable, whether "screen users need to know that an image of text is an image", and whether the obligation is programmatic and if so over which part — role, accessible name, or both (#494). Observes that role and name already appear to be covered by other requirements, so if that is not what this means, nothing is left. Recommendation is to remove the requirement.

Agrees the term is ambiguous but proposes a fix rather than deletion (#605): "A detectable element is one that can be identified programmatically in code and is presented to users in a way they can perceive." Points out that the only place the concept is currently explained is the non-normative Test section, which is not a basis for consistent interpretation or enforcement.

Folding code inspection and screen reader inspection into one test case invites incorrect interpretation; JasonAment proposes splitting them into parallel tests with alternate conditions — check the markup where a code inspector can reach the image, and use a screen reader only where the code cannot be checked (#606). mraccess77 adds that the accessibility API should be checked before jumping to a screen reader test.

Raised as a review comment on PR 350 and carried into #357: does this forbid CSS background images unless they are also marked up as images, and how does it square with the decorative-image requirement that such images be programmatically hidden? If an image is hidden it cannot be determinable as an image, which suggests the requirement is really about images that convey meaning. scottaohara later confirmed the draft preview updates to both requirements addressed this, and adampage closed the issue on 2026-04-01 after verifying the editor's draft.

MakotoUeki asks whether "non-decorative images" can simply be defined as "images that convey meaning", and whether in HTML using an img element satisfies the requirement (#467). mraccess77 answers no: use of img does not by itself mean the image is anything other than purely decorative.

Pushes to revisit his "Meaningful images have a text alternative" proposal against the current draft's goal that users have equivalent alternatives for images (#272). Cites WebAIM's finding that nearly a third of images on popular home pages have missing, questionable or repetitive alternative text, and argues there is no agreement on what an "equivalent" even is — ask ten experts and get ten answers. Wants a more scalable, consistent approach that works without technology changes and adapts as technology shifts, and points to slides 11-17 of an earlier working-group presentation on inter-rater reliability.

DavidMacDonald opened #197 noting that disabled interface elements work badly for people with low vision precisely because WCAG 2 exempts them from 1.4.3, and proposed requiring either 3:1 contrast or an icon marking the element as disabled. bkimmel seconds the problem, particularly where disabled states are used to signal future potential — fill these in and you can submit — calling the exemption a large safe harbour that cuts against the Perceivable goal. bkimmel is explicitly unsure an icon is the right remedy.

Would rather see some minimum contrast applied to solve readability than have WCAG start demanding icons everywhere, which impinges on visual design decisions. Suggests a more general intent of "indicating that something is disabled" as the flexible form. Also notes a likely crossover with how user agents themselves indicate disabled state.

Points out that "Interactive elements distinguishable" is adjacent to this problem, but the definition of interactive element — responds to user input and has a distinct programmatically determinable name — excludes disabled elements, which instead fall under non-interactive element. Since disabled elements are not mentioned in the examples or notes around that definition, he questions what the group actually intends, and floats broadening the term or adding a new one for elements that exist to be interactive but may conditionally be disabled or read-only. Flags this provision as also applicable and links w3c/wcag#5053.

Filing for the COGA Task Force in #783, notes the provision requires that information explaining why a control is disabled be available but says nothing about timing or persistence. A snackbar that vanishes after three seconds fails a user with slower processing speed. Recommends requiring explanations be persistent and visually co-located, and asks that this be checked for compatibility with "Notifications adjustable" in the User Control section. Cites MCU 3.1.2, 3.2.1, 3.7.5 and A.4.

The provision requires interactive elements to be visually distinguishable from static content without interaction and to include visual cues on how to use them, but the defined term covers only elements that respond to user input and have a distinct programmatically determinable name. Disabled elements therefore fall outside it and instead match non-interactive element, an element that does not respond to user input and does not include sub-parts. Because disabled elements are not named in the example or notes around that definition, adampage asks what the group intends and suggests broadening the term, or adding a new one, for elements that exist to be interactive but may conditionally be disabled or read-only. Links w3c/wcag#5053 as related.

DavidMacDonald opened #197 in 2019 proposing that disabled UI elements meet 3:1 contrast or carry a disabled icon, since WCAG 2 exempts them from 1.4.3 and that hurts low-vision users. bkimmel seconded the problem — disabled states used to advertise future interaction create a large safe harbour — while doubting an icon is the answer. patrickhlauke preferred a minimum contrast plus a general intent of indicating disabled state, arguing WCAG cannot start demanding icons everywhere, and noted a possible crossover with user agents' own disabled styling.

Opened #181 arguing the 3-versus-5-second split is hard to measure and has no rationale: a screen reader user is not less patient than a sighted one, and the two-second gap just adds complexity for testers. Also questions why autoplaying audio sits under Perceivable while auto-updating content sits under Operable, when unstoppable loud audio blocks operation exactly as animation does. His opening recommendation is to drop the autoplaying audio criterion altogether and add its requirement to 2.2.2 or its WCAG 3 equivalent, so the factors are assessed together. When alastc floats increasing the time on 1.4.2, Wildebrew agrees, recommending 1.4.2 change from 3 seconds to 5 to keep backwards compatibility, and treats WCAG 3 as the opportunity to group all page-level sound and animation together.

alastc notes the limits were set around 14 years earlier and no explanation is to hand, and that changing them would likely be backwards-incompatible — content passing WCAG 2.2 might not pass 2.0 or 2.1 — and he floats increasing the time on 1.4.2 as the alternative, while asking what the benefit would be given how long it has been that way. bruce-usab offers the historical guess that annoying sounds used to start immediately while animation and video took a few seconds to load, and five seconds of unwanted music was plainly too much. He does not claim the distinction is coherent, but would rather not make this change in the 2.x series.

julierawe opened #552 carrying a January 2026 survey comment from sydneycolemanfromgoogle that the requirement will be incredibly challenging for parties without dedicated writing support and does not seem to add significantly to understanding. julierawe's answer is procedural and tooling-based: the requirement was moved from core to supplemental after the survey closed, which may resolve part of the concern, and free AI tools already flag complex sentence structures, so WCAG 3 could encourage them to call out nested clauses specifically.

Concedes the requirement takes real work and is very hard without someone who works on language, but notes few sites have nobody working on content, so difficulty is not the objection. Accepts that removing nested clauses generally does improve understanding, much more so for deep nesting. His actual complaint is that the requirement is too simple to be very useful: clear writing is hard to test because people disagree on what is clear, and rules differ between languages so a test built for one is often useless in another. A paragraph in his comment about the requirement not differentiating by depth of nesting is struck through.

Argues in #569 that clause nesting is not inherently a readability problem. The English centre-embedded example about the rat, the cat and the dog is genuinely hard to process, but the equivalent Japanese structure is unremarkable for native speakers, and the same holds for Korean and other head-final languages. Concludes that the real source of difficulty varies by language — word order ambiguity, unclear referents — and that treating nested clauses as a general problem overgeneralises from English.

In #529 sydneycolemanfromgoogle asked whether "aced" should be replaced in a pass example as an idiom that may be hard to translate; hidde changed it to "did well on" in commit b1351ad and closed the issue on merge. In the still-open #530 sydneycolemanfromgoogle notes the listed nesting conjunctions may read as exhaustive when words like "that" also qualify, and supplies a rewritten test procedure making the list open-ended.