Image Alternatives Available

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.