Re: img@relaxed CP [was: CfC: Close ISSUE-206: meta-generator by Amicable Resolution]

Henri Sivonen 2/8/'12,  9:57
> On Thu, Aug 2, 2012 at 2:58 AM, John Foliot:
 
>> However, wrap a link around that image: <a 
>> href="http://validator.nu"><img src="567dfg.jpg"></a> and with JAWS/IE it 
>> reads out the file name of the image; meanwhile with NVDA/FF it reads out 
>> the full URL, which given some of the dynamically named URLs we see today 
>> can be down-right painful.
>
> It would be possible to have different default validator behavior for
> images that are descendents of <a>.

To me, this was one of the most annoying things with the meta generator 
exception - that it excepted even image links.

If Ted's proposal would say that @incomplete should not (at least not by 
default) apply in such cases, then that would bring the two proposals 
closer to each other.

Could you support such a thing?

  ... snip ...
 
>> Upon reflection, I guess I've changed my mind.
> ...
>> So if a generator tool *MUST* insert something into the code, the least 
>> objectionable solution to me would be to insert alt=""
>
> That's the reasonable answer if you disagree with the assumption
> underlying Ted's CP. Thanks. Do you have data or anecdotes about
> whether screen reader users out there outside WAI agree with you?

I wonder if you could support the following variant of John's position:

An empty @alt _could_ probably work _if_ the img _also_ has a @role=img. 
Example:

<img src=foo role=img alt="" >

I suppose that according to WAI-ARIA, then such an img would be considered 
significant, hence it would cause a screenreader to try to repair for 
missing alt.

Or to put it another way: To include an empty @alt in combo with @role=img, 
ought to be equivalent with omitting both the @alt and the @role=img. 
Except that it could have specific semantics with regard to validation: the 
semantics of 'incomplete'.

So instead of a new attribute, how about attributing the @relax/@incomplete 
semantics to the combination of empty @alt plus @role=img ?

Yes, text browsers would need to learn this new semantic. That is a con. 
Another con is that it goes a little bit against the pet idea of some that 
an omitted @alt has the semantic that the img is significant.

The pro is that it supports the trend of better and better ARIA support. 
Another pro is that it is - or seems - simpler to operate with the 
dichotomy 'empty vs non-empty @alt' as opposed to also include the third 
option of no @alt  - in combination with a fourth, new attribute. (The no 
@alt option may make more sense to hand authors?) This way we avoid adding 
any new attributes and instead deepens the semantics of the attributes we 
have. Which should be no more complicated than HTML5's already new 
semantics for the lack of @alt.
--
Leif Halvard Silli

Received on Thursday, 2 August 2012 10:29:25 UTC