- From: Ramón Corominas <rcorominas@technosite.es>
- Date: Wed, 27 Nov 2013 19:20:27 +0100
- To: james.nurthen@oracle.com
- CC: RichardWarren <richard.warren@userite.com>, Marco Zehe <mzehe@mozilla.com>, Detlev Fischer <detlev.fischer@testkreis.de>, HTML Accessibility Task Force <public-html-a11y@w3.org>, WCAG <w3c-wai-gl@w3.org>, public-comments-wcag20@w3.org
James wrote: > I don't see how a missing alt text, when the text alternative is > supplied by another means such as aria-label, aria-labelledby or even > title, fails 1.1.1 - assuming they are accessibility supported. Please define what is "accessibility supported" in this context and for how many/what kind of AT and in how many/what Operating Systems and how many/what devices. Are text equivalents only for screen readers? I must honestly admit that I don't know how many voice recognition applications are able to interpret and interact with ARIA attributes (or to which level of support). I also don't know many tools used by people with cognitive disabilities that convert text into easy-to-read or similar versions. I don't know if certain people with motor disabilities prefer to disable images and resize text because they have a bigger area to click. I don't know if people with low vision could prefer to disable icons because they find them difficult to see or understand, or because they are not resized when the user increases the text size. Please remember that WCAG 2.0 guideline 1.1 also states: "Guideline 1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language." I see @alt being changed into large print when someone disables images and increases text size. I can also imagine it changed to other forms via a "translation" system that creates an easy-to-read version of the content including text alternatives in a simplified text-based browser. Of course, this might also be done with the information in the ARIA attributes, but as far as I know they are designed to be always visually hidden and not presented to sighted users of any kind. Someone could also argue that, according to a strict interpretation of the definitions in WCAG 2.0, any @data- attributes (or new custom elements, or even through ::before or ::after pseudoelements) would also be valid to meet the SC *if* they gain accessibility support. Maybe some browser or AT vendors decide to implement vendor-specific @data- attributes or custom elements that will then be "supported", although they are not in any spec. So, in my opinion, the point here is if the WCAG WG accepts to soften the failure to accept *anything* that has enough accessibility support, even if violates other W3C specs. @alt is still a required attribute for images (at least in HTML). If this is the case, then I would suggest to suppress also: a) F70: Failure of SC 4.1.1 due to incorrect use of start and end tags or attribute markup b) F77: Failure of SC 4.1.1 due to duplicate values of type ID Ok, the normative text of SC 4.1.1 is more clear than SC 1.1.1, but why consider these always as failures if browsers and AT sometimes read the content without generating accessibility issues? Please suppress the entire SC! For example, how can the following cause any accessibility barrier and why consider them as strict failures?: 1. <div class="hello" class="hello">Hello</div> 2. <div id="hello"><div id="hello">Hello, world</div></div> 3. <div style="display: inline"><span>Hello,</div> World</span> c) F17: Failure of SC 1.3.1 and 4.1.1 due to insufficient information in DOM to determine one-to-one relationships (e.g., between labels with same id) in HTML d) F62: Failure of SC 1.3.1 and 4.1.1 due to insufficient information in DOM to determine specific relationships in XML These would only be failures if accessibility support is really inconsistent among different AT, but not as a general rule... Maybe all AT use the same "patching algorythm" to deduce the relationships. For example, screen readers could use the preceeding <label> of any edit box to determine the text label for that control. If this is accessibility supported in a consistent way, the following code would not fail 1.3.1: <label>User</label> <input type="text" /> <label>Pass</label> <input type="password" /> I guess that if we review all failures we can find more of this kind that should also be removed or softened to accept a wider range of possibilities that are accessibility supported. Therefore, I think that accessibility support can never be a decisive factor. Instead of that, consistency between different W3C specs is IMO a much better approach. So even if validation is not equivalent to an accessibility issue, softening F65 makes me feel that WCAG WG is saying: "hey, you don't have to care about following other W3C specs because validation -in this case- does not affect -at least certain profiles of- disabled people". If this is the message that we want to convey then please remove SC 4.1.1 as soon as possible, and remove/soften also any failure that is not always a failure if accessibility support is "enough". Regards, Ramón.
Received on Wednesday, 27 November 2013 18:21:06 UTC