- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 10 Jul 2009 13:24:12 +0300
- To: Jan Richards <jan.richards@utoronto.ca>
- Cc: Janina Sajka <janina@rednote.net>, Sam Ruby <rubys@intertwingly.net>, Chris Wilson <Chris.Wilson@microsoft.com>, Michael Cooper <cooper@w3.org>, Dan Connolly <connolly@w3.org>, Mike Smith <mike@w3.org>, WAI XTech <wai-xtech@w3.org>, W3C WAI Protocols & Formats <w3c-wai-pf@w3.org>, "wai-liaison@w3.org Liaison" <wai-liaison@w3.org>, John Foliot <jfoliot@stanford.edu>, www-archive <www-archive@w3.org>, "public-html@w3.org WG" <public-html@w3.org>
(Added public-html to CC per HTML WG telecon minutes.) On Jul 9, 2009, at 16:28, Jan Richards wrote: > Henri Sivonen wrote: >> On Jun 11, 2009, at 04:30, Janina Sajka wrote: >>> This document is also available at the following URI; >>> http://www.w3.org/2009/06/Text-Alternatives-in-HTML5 >>> >>> We look forward to working with you to make HTML 5 the best >>> accessibility solution yet. >> Thank you for documenting the WAI CG consensus. >> I have three questions related to software generating <img> elements: >> 1) The user creates a new HTML document in an HTML5-compliant >> future version of a Dreamweaver-like product and saves it with a >> name. The user then drags an image file from the Finder onto the >> document window and the image is inserted into the document. The >> user presses command-S and then command-Q. What attributes should >> the generated <img> element have? > > JR: The consensus document does not attempt to dictate syntax for > this case, but the following options agree with the consensus and > Public WD of ATAG 2.0 (http://www.w3.org/TR/2009/WD-ATAG20-20090521/): > > a. The tool leaves @alt out entirely, so that the code produced is > invalid. That doesn't make sense. Invalid means that authors or tools acting on their behalf must not generate what is defined to be invalid. It doesn't make sense to have a situation where ATAG 2.0 says "do X" and HTML 5 says "you must not do X". If there's consensus that it's good for ATAG 2.0 to say "do X", then we should make sure HTML 5 allows doing X--i.e. doesn't make it invalid. (It's unclear to me where ATAG 2.0 actually says that alt can/should be omitted in this case. Specifically, B.2.4.3 is too abstract for me to apply concretely to HTML5 with confidence that my application is what ATAG 2.0 meant.) > b. The tool makes use of some kind of 'autogenerated' or 'missing' > attributes as per this paragraph in the consensus: > "In order to address both the validity and human generation > concerns, we do not oppose the creation of 'autogenerated' and > 'missing' attributes where either one of these could be used to make > an image that does not have any human-generated text alternatives > valid. (Note: It is important that this marker is not included in > the alternative text string itself.)" Is there a WAI CG consensus on what the marker should concretely be in the case I outlined? Do you mean an attribute named "autogenerated" or "missing"? ATAG 2.0 B.2.4 doesn't help me understand what ATAG 2.0 wants HTML generators to do when there aren't "relevant sources" that B.2.4.3 doesn't exclude and the user doesn't cooperate affirmatively per B. 2.4.2(a). >> 2) The user takes a photo with his/her cameraphone and uploads it >> to a service such as Brightkite. The user has the option to add an >> SMS-like short caption that will be rendered in addition to the >> photo in visual browsing settings but is not forced to add a >> caption. What attributes should the generated <img> element have >> when the photo appears immediately on the Web? (Brightkite now says >> alt="Photo-feed". Reference: http://brightkite.com/objects/80d0f32c11e311deab31003048c10834) > > JR: If the photo appears "immediately on the Web" (without any > "authoring session") or if the author ignores prompts for the short > caption during their authoring session, then the tool may add an > @alt value as long as it is a value that the user agent wouldn't > know. So because the fact that this is a "photo" is information the > user agent can't easily detect, I would guess that detecting that a bitmap is a photo with a pretty good confidence would of the easier kind of signal processing tasks, so I'm suspecting it's a case of "don't" rather than "can't", but I haven't programmed it to find out easiness myself, so OK. > alt="Photo-feed" is ok (though of course very suboptimal from a user > perspective) OK. >> 3) Point #5 under "Use Case 2 (author using a photo sharing site)" >> instructs photo sharing sites to generating alt="Photo 1 of 50 of >> album Paris 2009". Why is this approach recommended instead of >> generating aria-posinset="1" aria-setsize="50" and an alt attribute >> that doesn't repeat the set position data, e.g. alt="Paris 2009"? > > JR: To clarify, this isn't an "instruction". This is an example of > the kind of information that "allowed" because it is more readily > available to the authoring tool than to a user agent (hopefully with > an accompanying 'autogenerated' attribute). OK. If a W3C publication were to give this example, would using aria- posinset="1" aria-setsize="50" set a better example than putting the "n of m" data into the alt attribute? -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Friday, 10 July 2009 10:24:59 UTC