Re: WCAG considering amending F65 to NOT fail missing ALT text if title or aria-label is present

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