W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: feedback requested on WAI CG Consensus Resolutions on Text alternatives in HTML 5 document

From: Jan Richards <jan.richards@utoronto.ca>
Date: Thu, 20 Aug 2009 08:06:49 -0400
Message-ID: <4A8D3C59.1080308@utoronto.ca>
To: Henri Sivonen <hsivonen@iki.fi>
CC: HTMLWG WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
Hi Henri,

Henri Sivonen wrote:
> On Aug 19, 2009, at 23:43, Jan Richards wrote:
>>>>>> When used, a "missing" signal (however this might be encoded - as 
>>>>>> long as it is not in the @alt string) would communicate to the 
>>>>>> user agent that the @alt value should not be trusted.
>>>>> What concretely is this envisioned to mean for user agent behavior?
>>>> Since the semantic meaning would be "don't trust the @alt string" I 
>>>> would think the behaviour would be the same as it is now when @alt 
>>>> is fully missing.
>>> This seems more problematic than a pure validator pragma. Why would a 
>>> generator generate an alt string and a signal for UAs to completely 
>>> ignore it? More importantly, having an "user agents should ignore alt 
>>> completely" marker would pose a backward and forward compatibility 
>>> problem: If the markup generator wants UAs to ignore the alt 
>>> completely, generating some alt and an "ignore" marker would make old 
>>> UAs not ignore the alt. If early adopters use the "ignore" marker 
>>> while testing in current UAs, future UAs would lose potentially 
>>> useful text alternatives.
>> I can see the backwards compatibility problem, but not the forwards 
>> compatibility problem. Why would testers add the "ignore" marker while 
>> testing in current UAs?
> Given enough rope, Web authors do the wildest things for the craziest 
> reasons. However, here's a plausible non-crazy failure scenario:
> Author A creates a document using an authoring tool and fails to make 
> the document accessible. The authoring tool inserts the "ignore" marker. 
> Later, author B in author A's organization addresses the problem that 
> the document is inaccessible. Author B adds sensible alt text using a 
> text editor. While author B has read introductions to Web accessibility 
> to know about alt, author B isn't aware of the finer points of HTML 
> syntax and fails to remove the "ignore" marker. Now the document is 
> still inaccessible in UAs that honor the "ignore" marker. Author B could 
> even test the document in older UAs without noticing the problem.

I see. Perhaps this could be addressed somewhat by advising authoring 
tools to automatically undo the "missing" mechanism if an author edits 
the @alt value.

>>> If the user of the tool inserts an image (outside <figure>, etc. 
>>> special constructs) and doesn't provide a text alternative or rejects 
>>> (which must be an option under ATAG 2 B.2.4.2.a) a tool-suggested 
>>> text alternative but doesn't flag the image as omissible from AT 
>>> presentation, as far as I can tell, generating role=presentation 
>>> would be wrong by analogy with ATAG 2 B.2.4.4 and generating any alt 
>>> would be wrong per ATAG 2 B.2.4.3 when the tool has no relevant 
>>> sources that the UA wouldn't have.
>> If the author rejects the suggested @alt value, ignores the 
>> prompts/checks for their own @alt, and turns off the "missing" 
>> mechanism then....yes, invalidity will result, but at some point, 
>> isn't that the author's choice?
> I meant in the absence of a "missing" mechanism. If a "missing" 
> mechanism is introduced, it makes no sense for authoring tools to have 
> UI for micromanaging the "missing" mechanism.



Jan Richards, M.Sc.
User Interface Design Lead
Adaptive Technology Resource Centre (ATRC)
Faculty of Information
University of Toronto

   Email: jan.richards@utoronto.ca
   Web:   http://jan.atrc.utoronto.ca
   Phone: 416-946-7060
   Fax:   416-971-2896
Received on Thursday, 20 August 2009 12:07:31 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:50 UTC