Re: User supplying image but not text alternative

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.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Thursday, 21 August 2008 06:21:08 UTC