Re: User supplying image but not text alternative

Hi Henri,

Just to clarify, I didn't say ATAG ever requires "alt" to be omitted.

All I meant was that ATAG doesn't have a strict requirement that tools 
always create "valid" code (where valid is defined by a markup 
language's authors).

 From the perspective of accessibility-aware authoring tools (especially 
re: checking), the key issue is discoverability of accessibility 
problems. A checker needs to be able to distinguish: (a) an alt missing 
on purpose (e.g., when img is pure decoration), from (b) an alt missing 
by oversight/negligence/etc.

In the past one way to do this was to treat alt="" as (a) and the 
absence of an alt attribute as (b)...but of course that breaks validity 
as you say.

In a future HTML then it would be nice to have a valid way of 
differentiating (a) from (b). An example was Matt May's @noalt which an 
HTML generator could add. I commented on Matt's proposal here: 
http://lists.w3.org/Archives/Public/wai-xtech/2008May/0199.html

Cheers,
Jan




Henri Sivonen wrote:
> On Aug 20, 2008, at 16:47, Jan Richards wrote:
> 
>> There's a couple of relevant guidelines...
>>
>> The first is "Guideline B.1.3 Ensure that automatically generated 
>> content is accessible." 
>> (http://www.w3.org/TR/2008/WD-ATAG20-20080310/#gl-generate-access-content) 
>>
> 
> It seems to me that in this case, the HTML generator can't fix the 
> content to be accessible. It can't realistically coerce the user to be 
> cooperative. It needs to do *something* to finish processing (throwing a 
> fatal error isn't a business-realistic alternative for media sharing 
> sites), so it's a question of *what* it should do not to make the result 
> more inaccessible than necessary. (I'm assuming that e.g. stuffing a 
> file system path in alt would make the end result more inaccessible than 
> necessary.)
> 
>> Its success criteria require "automatically generate[d] content [to 
>> meet] the level 'A' Web content accessibility benchmarks at the 
>> conclusion of the automatic generation process (e.g., when inserted 
>> into the existing content)"
> 
> As far as I can tell, WCAG 2.0 as currently drafted does not cover this 
> case, and the HTML generator cannot meet the requirements for the cases 
> that WCAG 2.0 does cover.
> 
>> Its notes ("Related", "Accessibility Note 1", "Accessibility Note 2") 
>> are clear that if accessibility information is required from authors 
>> during the automatic generation process, see the author will need to 
>> be prompted. But that tools are not responsible if the author then 
>> ignores prompts for accessibility information or provides faulty 
>> information.
> 
> Given how people use existing media sharing sites, it seems reasonable 
> to assume that a private person who dumps hundreds of vacation photos 
> online in one go often will not cooperate with providing text 
> alternatives even if prompted. (For the purpose of this question from 
> the point of view of the markup generator, it doesn't matter if that's 
> right or wrong, although I don't think it's unreasonable for the user 
> not to cooperate--particularly if the user's ability to do text input is 
> lower than his/her ability to trigger the camera.)
> 
>> So for a media media sharing site, I interpret this to mean:
>> - since information is required from the author to make a generated 
>> page of photographs accessible, the author should be prompted (NOT 
>> forced ) to add it. ATAG 2.0 never advocates forcing because it just 
>> leads to alt="@#$%".
> 
> I think this is a reasonable position.
> 
>> - assuming the author ignores the prompt the tool is not required to 
>> enter anything for the author - but they must continue to allow the 
>> author to add the required information if they so desire in the future 
>> (and an unobtrusive flag would help meet ATAG's checking requirement).
> 
> I think this is a reasonable position.
> 
>> - sorry, but whether or not the resulting content (i.e., with a 
>> missing alt attribute) would be valid is up to folks who designed the 
>> markup language.
> 
> I think a stance that conformance to ATAG requires a software program 
> targeting HTML 4.01 (where alt is required) output to omit alt under any 
> circumstances is an unreasonable position. If we have a software program 
> that generates output in format foo in such a way that the internals of 
> the format are hidden from the user (i.e. it's not a text editor or a 
> hex editor), no user input or lack thereof should make the program 
> violate the syntactic requirements of format foo.
> 
> To give an example that will hopefully be intuitively recognized as 
> absurd: A bitmap editor outputs PNG files. It's not a hex editor, so the 
> editor hides the internals of the PNG format from the user. If the user 
> makes an image that is deemed inaccessible (let's say low contrast for 
> the sake of example), would it make sense for accessibility guidelines 
> to require the image editor to emit PNG chunks whose format (say CRC for 
> the sake of example, since CRC errors could be made recoverable) violate 
> the PNG spec?
> 
> However, if ATAG takes the position that omitting alt in this case would 
> be best, then HTML5 should be specified to allow it to be omitted in 
> this case.
> 

-- 
Jan Richards, M.Sc.
User Interface Design Specialist
Adaptive Technology Resource Centre (ATRC)
Faculty of Information (i-school)
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, 21 August 2008 13:25:53 UTC