Edit comment LC-2961 for Accessibility Guidelines Working Group

Previous: LC-2958 Next: LC-2950

Comment LC-2961: Comment Shortname:; Commenter:; Message-id:; Section of the document concerned:

or; Refinement of the section concerned:; Status:
assigned to; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
https://github.com/w3c/wcag/pull/33

Changing accessible name from rendered/visible text generally causes accessibility issues. Especially, changing accessible name completely different one from rendered/visible text causes serious accessibility issues.

ARIA 1.0 Recommendation provides some examples of similar issues. In a note of |aria-hidden|
http://www.w3.org/TR/2014/REC-wai-aria-20140320/states_and_properties#aria-hidden

Note: Authors are advised to use extreme caution and consider a wide range of disabilities when hiding visibly rendered content from assistive technologies. For example, a sighted, dexterity-impaired individual may use voice-controlled assistive technologies to access a visual interface. If an author hides visible link text "Go to checkout" and exposes similar, yet non-identical link text "Check out now" to the accessibility API, the user may be unable to access the interface they perceive using voice control. Similar problems may also arise for screen reader users. For example, a sighted telephone support technician may attempt to have the blind screen reader user click the "Go to checkout" link, which they may be unable to find using a type-ahead item search ("Go to…").
As Example 1 of ARIA7 changes accessible name from "Read more..." to "Storms hit east coast", people who use voice control or who are blind and communicating with sighted person may face issues.

Thus we should get rid of Example 1 of ARIA7.
takenspc ARIA7 Remove Example 1; Related issues: (space separated ids); WG Notes: I see three options: Option 1: Remove example 1. Example 2 is a better example because it includes both the link text and additional on-screen text. Option 2: Keep example 1 and provide example of where a replacement for link text would be a good idea. Perhaps an example where the link was a symbol such as ">>" or ">" but where on-screen text exists. I can't think of a good example where there would be on-screen but you wouldn't want to include it in the link text. Even for a footnote or search result page number example, you'd want to include the footnote or page number in the accessible name. Proposed decision: Remove Example 1.; Resolution: Thank you for your comment. The working group has reviewed the comment and agrees that the example could cause accessibility issues for some users with disabilities and should be removed from this technique. The group also agreed to update example 1 as follows by adding a redundant referenence to the "Read more text". Example 1: Providing additional information for links This example will mean that the link text as shown on screen is then used as the start of the accessible name for the link. Popular screen readers like JAWS and NVDA will announce this as: "Read more ...Storms hit east coast" and will display that same text in the links list which is very useful for screen reader users who may browse by links. <h2 id="headline">Storms hit east coast</h2> <p>Torrential rain and gale force winds have struck the east coast, causing flooding in many coastal towns. <a id="p123" href="news.html" aria-labelledby="p123 headline">Read more...</a></p> NOTE: Technique ARIA 8 addresses the use of aria-label when link text may not be available and thus also provides a solution for that particular scenario. We hope this addresses your concerns.; (Please make sure the resolution is adapted for public consumption)