- From: Robert Burns <rob@robburns.com>
- Date: Thu, 16 Aug 2007 21:02:20 -0500
- To: Jon Barnett <jonbarnett@gmail.com>
- Cc: public-html@w3.org
HI Jon, On Aug 16, 2007, at 4:50 PM, Jon Barnett wrote: > > On 8/16/07, Robert Burns <rob@robburns.com> wrote: >> >> This is example example where Ian hasn't even taken his own >> advice. He has >> rightly suggested that we all focus on problems statements and use- >> cases. >> The changes he's made to the draft certainly reflect an important >> problem-statement /use-case. However, the solution fails to >> benefit from >> the WG process. > > I don't understand what you mean by this or what you're implying. I think following Ian's advice, the proper thing to do would be to introduce the problem he's trying to solve in the draft (which right now has to be gleaned from a careful reading), and then solicty the feedback of this WG. That's an approach that starts from problems instead of jumping to solutions. > > In case you haven't seen it, this is Hixie's message tot he WHATWG > list: > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-August/ > 012378.html > It's just a response to various messages to the WHATWG list, but it > shows some of the reasons for the latest changes. > > As a result, we now have a draft that is a much better starting point > for discussion than before. We voted on a document for a starting point and gained consensus in the group for a starting point. Its in appropriate to change that starting point after that fact. The edits to the draft from this point on should reflect the HTML WG. The WhatWG needs to be put on the back burner now. We didn't adopt a dynamic WhatWG HTML5 draft back in May. We adopted a specific version of the draft. The evolution of that draft from that point on should reflect the views of this WG. Certainly as a member of the WG, Ian can draw on all sorts of interactions and experiences in giving input into the WG But as an editor, the changes should directly reflect the discussions here and not elsewhere. If Ian doesn't see the types of discussion here he wants to see, then he should prod us to start those discussions. >> I can't think of a good name for this attribute, but consider >> something like >> @embedrel (required) for now (name suggestions welcome). The value >> of this >> attribute would reflect the scenarios identified in the recent >> changes to >> the draft. missing, icon, decorative, seecontext, seefallback. The >> value >> 'missing' would be the default value, unless '@a't had a string >> (or perhaps >> some other contingencies for content backwards compatibility ) so >> not >> setting either @alt or @embedrel would be considered 'missing'. >> > > I am by no means opposed to a new attribute for indicating that an > image intentionally has no @alt text, i.e. a new attribute to do what > omitting @alt does now. The suggestion was @noalt, Maciej has > mentioned it in a recent message. If it can be proven that either (a) > enough UAs treat missing @alt the same as alt="" or (b) enough authors > omit alt when they really mean alt="", then I'd be in favor of that > attribute. > > However, I don't understand what specific problems these keywords > solve. These keywords are addressed at the same problems Ian's changes to the draft are aimed at (at lease as I interpolate the problems that haven't been stated explicitly as problem statements). Each keyword corresponds to one of the 5 (I dropped email, because I think that's a completely different axis than the other scenarios) that Ian lays out in the draft. By combining this new @embedrel attribute and its keywords with @alt, we do several things: 1) we provide crucial information to conformance checkers to actually do their job and reflect the intentions of the draft; 2) we continue to place an importance on alternative equivalent fallbacks so that authors learn that it is important; 3) we provide important information to AT and browsers with images turned off (for example deciding whether to download an image might be effected by whether its an 'icon' or 'decorative' or 'seecontext', etc). > For example, alt="" works well when an image is purely decorative - a > blind user can ignore it. alt="" also works well when an image's > alternate text would just be redundant: <img alt="" > src="home.jpg">Home - a blind user can ignore it. What problem is > solved by using foo=icon or foo=decorative? I don't see how > accessibility is served by making the distinction. Those two are largely the same in my mind (they have subtle differences). However, the keywords I defined were built on Ian's work on the draft and reflect the 5 scenarios (6 - 1 about email) that Ian outlines. > Why does an aural browser need to distinguish between various roles of > embedded content? It's not the aural browser's job to understand the > role of images - it's the aural browser's role job to replace that > image with appropriate content by (a) speaking the alternate content > seamlessly in place of the image (b) saying nothing at all because > omitting the image doesn't change the meaning of surrounding content > or (c) saying something to indicate that an image is missing (and > possibly reading its @title) because that image has no appropriate > alternate text and cannot be omitted from the document without > changing its meaning. For a browser such as lynx, it could let a user know whether its worthwhile to bother downloading an image and loading on some other device or into some other application. For users of AT, it can let them know whether this page has content that will ever be decipherable to the user. Should they try to listen or braille read the document yet another time. Or is it clear from the keywords (or lack of keywords) that this page was just not setup properly for their consumption (complaints could be lodged). I think the relation between these keywords, the default value for this @embedrel attribute and the value for @alt provide a nice solution to the problem Ian is trying to address (at least as I understand it). We can say that the @embedrel attribute is required. Its default value is 'missing' when @alt is missing or set to alt=''. So for the following elementt s: 1) <img> 2) <img embedrel='missing'> the value of embedrel is 'missing'. These all reflect the important information that the alternate for this content is missing. It doesn't matter whether an authoring tool couldn't provide the information (2), or its simply a careless author (1) or not targeted at all to be accessible (2) in an email application. The interesting part for the conformance checker or other UA is that and to the user is that the information is missing. Its not decorative or an icon where comprehending the document or subdocument wouldn't be a problem . Its just missing: that part of the document will be incomprehensible to the user. For 1) <img alt=''> the default value for @embedrel would be 'decorative'. This would be backwards compatible with HTML 4 content for documents that actually follow that convention. However, for HTML5 conforming authors and editing UAs, the @embedrel attribute provides a much less ambiguous approach. With @embedrel, conformance checkers, AT and other UAs can distinguish between alt='' that means: 1) decorative (decorative) 2) icon (icon) 3) I'm just trying to get this document to validate (missing) 4) I made this with a visual editor that threw this on here to make it validate (missing) Those are the important distinctions Ian outlines. However, this approach allows us to state positive authoring conformance norms such as authors must INCLUDE a @embedrel attribute rather than authors must OMIT an @alt attribute. In the latter case its not possible to distinguish from sloppy HTML 4 or HTML5 authoring from conforming HTML5 authoring. Take care, Rob
Received on Friday, 17 August 2007 02:02:39 UTC