From faulkner.steve at gmail.com Mon Feb 4 11:48:04 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Mon, 4 Feb 2008 19:48:04 +0000 Subject: [html4all] ALT issue redux In-Reply-To: References: <9787ADE3-8D9A-44BC-B685-37A85191B7F8@IEEE.org> <1c8dbcaa0802010628x45b26516uf4348179dbf38572@mail.gmail.com> Message-ID: <55687cf80802041148g6837064ar82b2c430034b66f1@mail.gmail.com> HI All, thanks for the response. Al Giman wrote: ------ > I think that a better way to frame the argument is something like: > > > > 1. By the principles, HTML5 wants to support accessibility > > 2. By their charters, WAI groups (here WCAG) are the go-to > experts in matters of accessibility > > 3. WCAG requires @alt (WCAG1) or the function that in HTML4 > is provided by @alt (WCAG2) [editorial note -- add links] > > 4. By the principles, if it 'tain't broke, don't fix it. > > 5. Conclusion: barring the introduction of three fresh good > reasons for a change, the failure of the HTML5 draft to make > @alt on an across-the-board requirement (even if sometimes > it has the value of "") is a bug. Or do you have > reasons? > > > > Does this work for you? ------ Works for me. -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080204/3120f2e0/attachment.html From joshue.oconnor at cfit.ie Mon Feb 4 12:31:08 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Mon, 04 Feb 2008 20:31:08 +0000 Subject: [html4all] ALT issue redux In-Reply-To: <55687cf80802041148g6837064ar82b2c430034b66f1@mail.gmail.com> References: <9787ADE3-8D9A-44BC-B685-37A85191B7F8@IEEE.org> <1c8dbcaa0802010628x45b26516uf4348179dbf38572@mail.gmail.com> <55687cf80802041148g6837064ar82b2c430034b66f1@mail.gmail.com> Message-ID: <47A7760C.2060704@cfit.ie> Hi all, The last few posts on this issue have been positive. Cheers Josh From foliot at wats.ca Mon Feb 4 15:56:13 2008 From: foliot at wats.ca (John Foliot) Date: Mon, 4 Feb 2008 15:56:13 -0800 Subject: [html4all] ALT issue redux In-Reply-To: Message-ID: <00e201c86789$8b2b7280$993142ab@stanford.edu> Al Gilman wrote (in response to Laura Carlson): > > Since by the Principles propounded by the HTML Working Group they > *want* to support accessibility, let's build on that and find an > answer to *how* HTML5 supports accessibility that works. > >> According to WCAG alt is required. > > In terms of WCAG1 that is true. > > In terms of WCAG2 a text alternative is required. The > format specifics have been removed from the success criterion. The > difference matters. > > In looking toward HTML5 which may take longer to finalize that even > WCAG2, it is important to look at the trend, the nature of the > differences between WCAG1 and WCAG2. > > The HTML5 draft is clear that, at a moral level, the critical content > *should* have its text alternate, in the @alt attribute. > > When they say "none may be available, or obvious," the narrative > discussion suggests a division of labor where the photo-sharing site > provides the markup and the public provides the image content. > > It doesn't matter much whether it's a format rule or a WCAG rule that > has been violated; what is going to affect public behavior is things > like: ... > > The question in terms of deployment is "what is going to happen to > you or your content if you violate this rule?" It's not a question > of "is it a language rule?" or "is it an accessibility rule?" but > "what is going to happen?" OK, time to jump in... What is going to happen is that an image will exist that has *no* contextual data associated to it. Thus, by it's very nature, it will be inaccessible to those who cannot see the image. At best, adaptive technology will "know" that there is/are images in the document, but despite the well-meaning wishes of the HTML WG, no current amount of heuristic analysis will be able to suggest whether a specific image is critical, in-consequential, or somewhere in-between. Further, A.T. will be unable to determine whether this is by design, ignorance or by accident. The argument has been put forth by the HTML WG that ALT="" may in fact be "harmful" to accessibility (a claim, BTW, they have not been able to substantiate). However, even though today there exists many, many images with ALT="" (and are still functionally inaccessible to many users), it has emerged as the cowpath-de-jour. I respectfully suggest then that we both need to acknowledge the problem as well as suggest a way forward - but a way forward that insists that non-textual content, and specifically the image element, *must* contain the ALT attribute to be conformant - full stop. It has been suggested (by myself, but also by others) that some reserved values be created and referenced in the specification that could replace the current default of . A synopsis and related reading exists within the ESW Wiki at http://tinyurl.com/2v9c6f Images that lack either ALT="" (backward compatible), or one of the newly suggested reserved values (ALT="_none", ALT="_omit", ALT="_decorative", etc. - all values which *do* provide some contextual information) would then be non-conformant, and subjected to the following: > > Josh and I would seem to be agreed that "refuse to process > such a page in the browser" is justified for a critical-content image > that is lacking @alt. (I would amend that to read *any*, as how does the non-author determine what is critical vs. non-critical?) A solution such as this builds upon the current cowpath (ALT=""), and at the same time seeks to further enhance the semantic value of newly minted content, while still addressing the needs of Adaptive Technology. (As a further wrinkle, and building upon a different furor in a different camp, documents that render in quirks mode that lack any alt attribute could be "forgiven" and output as best as possible - quirky indeed) > > The problem with the immediate section about > > A key part of the content that doesn't have an obvious textual > alternative > > .. is the casual, colloquial way it is written. It neither meets the > need of software developers for a crisp rule they can program to, and > at the same time it irritates access advocates by allowing the > inference that it disagrees with the accessibility Recommendations. In the many go-rounds on this topic, another critical piece of information emerged, not obvious on the surface (or in the draft), but spoken of none-the-less. As it currently stands, omitting *any* alternative content rests primarily with the content author - it is a subjective decision that often may also be supported by authoring tools or applications (i.e. the photo sharing site), but the bottom line is that the decision is discretionary: "I am currently following HTML5 (omitting alt) as it wasn't really clear to me what would be a better solution given the single constraint I have: not finding it necessary to provide replacement text for all those images. This would take too much time for little benefit." http://annevankesteren.nl/2007/09/alt [REPEAT] ...too much time for little benefit... It is this "loop-hole" which both frustrates and frightens me. In contrast, the addition of reserved values can be programmatically accounted for in conformance checkers, accessibility "validators", etc. and the author "intent" is conveyed, even if the intent is to deliberately not provide contextual alternative(s) to images or other non-text items. > > I think that a better way to frame the argument is something like: > > 1. By the principles, HTML5 wants to support accessibility ...in so far as it does not impact on other critical goals. Witness the disappearance of @headers/@id, @longdesc, and the poorly documented (to non-existent) information alternatives to newly introduced elements such as @canvas > > 2. By their charters, WAI groups (here WCAG) are the go-to experts > in matters of accessibility > > 3. WCAG requires @alt (WCAG1) or the function that in HTML4 > is provided by @alt (WCAG2) [editorial note -- add links] > > 4. By the principles, if it 'tain't broke, don't fix it. > > 5. Conclusion: barring the introduction of three fresh good reasons > for a change, the failure of the HTML5 draft to make @alt on an > across-the-board requirement (even if sometimes it has the value of > "") is a bug. Or do you have reasons? > > Does this work for you? If we can hold them to this, then yes. I would further posit that author ignorance and non-ATAG conformant tools not be accepted as "good reasons", as both can and must change in the evolutionary process. Freezing time is only self-defeating. One final thought - Patrick Lauke wrote: > 4. it's broken because, in the wild, the proportion of images lacking > @alt (or with broken/incomplete/inappropriate @alt) is a few orders of > magnitude higher than that of properly @alt-ed images. this despite > making @alt mandatory for validation XHTML ...meanwhile: "This specification represents a new version of HTML4 and XHTML1, along with a new version of the associated DOM2 HTML API. Migration from HTML4 or XHTML1 to the format and APIs described in this specification should in most cases be straightforward, as care has been taken to ensure that backwards-compatibility is retained." - http://www.w3.org/html/wg/html5/#relationship "HTML 5, one vocabulary, two serializations" - http://www.w3.org/QA/2008/01/html5-is-html-and-xml.html If the new spec removes the previous mandatory obligation for @alt in XHTML1, how then can it be backward compatible to XHTML1, as it removes a requirement previously obliged? To my thinking it is a backward step, rather than a forward one. Or am I completely missing something here? Respectfully JF From redux at splintered.co.uk Mon Feb 4 16:17:27 2008 From: redux at splintered.co.uk (Patrick H. Lauke) Date: Tue, 05 Feb 2008 00:17:27 +0000 Subject: [html4all] ALT issue redux In-Reply-To: <00e201c86789$8b2b7280$993142ab@stanford.edu> References: <00e201c86789$8b2b7280$993142ab@stanford.edu> Message-ID: <47A7AB17.2060807@splintered.co.uk> John Foliot wrote: > If the new spec removes the previous mandatory obligation for @alt in > XHTML1, how then can it be backward compatible to XHTML1, as it removes a > requirement previously obliged? It is backwards compatible because valid XHTML1 will always also be valid HTML5. Also, browsers that currently support XHTML1 won't choke on missing @alt. Backwards compatibility (and the "two serialisations" thing) doesn't mean that HTML5 can simply be converted down to XHTML1 (in which case making a mandatory attribute optional *would* be a breach). I'm not defending the decision to make @alt optional, mind...just working out the logic that lets HTML WG do it while still following the backwards-compatibility principle. P -- Patrick H. Lauke ______________________________________________________________ re?dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com ______________________________________________________________ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ ______________________________________________________________ From redux at splintered.co.uk Mon Feb 4 16:22:37 2008 From: redux at splintered.co.uk (Patrick H. Lauke) Date: Tue, 05 Feb 2008 00:22:37 +0000 Subject: [html4all] ALT issue redux In-Reply-To: <47A7AB17.2060807@splintered.co.uk> References: <00e201c86789$8b2b7280$993142ab@stanford.edu> <47A7AB17.2060807@splintered.co.uk> Message-ID: <47A7AC4D.6000005@splintered.co.uk> Patrick H. Lauke wrote: > It is backwards compatible because valid XHTML1 will always also be > valid HTML5. Probably worth adding: only in the case of IMG/@alt, all other things being equal (which of course they aren't). And possibly: unless I'm misunderstanding the idea of backwards-compatibility. Is it "HTML5 browsers will be able to make sense of XHTML1/HTML4 documents" (my understanding) or "XHTML1/HTML4 browsers will be able to work with HTML5 documents"? Even if it's the latter, the fact that browsers don't throw an error when an XHTML1 image is missing the mandatory @alt could be explained as backwards compatible by the WG. P -- Patrick H. Lauke ______________________________________________________________ re?dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com ______________________________________________________________ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ ______________________________________________________________ From annevk at opera.com Mon Feb 4 16:37:01 2008 From: annevk at opera.com (Anne van Kesteren) Date: Tue, 05 Feb 2008 01:37:01 +0100 Subject: [html4all] ALT issue redux In-Reply-To: <47A7AC4D.6000005@splintered.co.uk> References: <00e201c86789$8b2b7280$993142ab@stanford.edu> <47A7AB17.2060807@splintered.co.uk> <47A7AC4D.6000005@splintered.co.uk> Message-ID: On Tue, 05 Feb 2008 01:22:37 +0100, Patrick H. Lauke wrote: > And possibly: unless I'm misunderstanding the idea of > backwards-compatibility. Is it "HTML5 browsers will be able to make > sense of XHTML1/HTML4 documents" (my understanding) or "XHTML1/HTML4 > browsers will be able to work with HTML5 documents"? Even if it's the > latter, the fact that browsers don't throw an error when an XHTML1 image > is missing the mandatory @alt could be explained as backwards compatible > by the WG. It's both actually, for some value of XHTML1/HTML4 browsers. -- Anne van Kesteren From joshue.oconnor at cfit.ie Tue Feb 5 03:19:15 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Tue, 05 Feb 2008 11:19:15 +0000 Subject: [html4all] ALT issue redux In-Reply-To: <00e201c86789$8b2b7280$993142ab@stanford.edu> References: <00e201c86789$8b2b7280$993142ab@stanford.edu> Message-ID: <47A84633.9050409@cfit.ie> > > Josh and I would seem to be agreed that "refuse to process > > such a page in the browser" is justified for a critical-content image > > that is lacking @alt. Just to be clear, I would not want the browser to refuse to render the page even if a critical alt is missing. That would be a situation where the cure is worse than the disease. > 3. WCAG requires @alt (WCAG1) or the function that in HTML4 > is provided by @alt (WCAG2) [editorial note -- add links] I want the @alt to be mandatory for critical content for conformance for WCAG 1.0 and also [insert new attribute here] for WCAG 2.0. That puts accessibility into the right domain. Should the browser still continue to render pages that don't conform, yes. Should authors right better code and mark-up content in a proper way, yes. Should the browser not render a page that is not proper or does not conform? No. Cheers Josh From faulkner.steve at gmail.com Tue Feb 5 03:31:59 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Tue, 5 Feb 2008 11:31:59 +0000 Subject: [html4all] ALT issue redux In-Reply-To: <47A84633.9050409@cfit.ie> References: <00e201c86789$8b2b7280$993142ab@stanford.edu> <47A84633.9050409@cfit.ie> Message-ID: <55687cf80802050331r58668c35y308579200294bb80@mail.gmail.com> To pick up Josh's point, There are many validation errors that don't cause browsers to stop processing the document in HTML 4 and presume that this will be the case in HTML5. Relying upon this criteria as one of the points to decide whether alt should be mandatory or not, is misguided. On 05/02/2008, Joshue O Connor wrote: > > > > Josh and I would seem to be agreed that "refuse to process > > > such a page in the browser" is justified for a critical-content image > > > that is lacking @alt. > > Just to be clear, I would not want the browser to refuse to render the > page even if a critical alt is missing. That would be a situation where > the cure is worse than the disease. > > > 3. WCAG requires @alt (WCAG1) or the function that in HTML4 > > is provided by @alt (WCAG2) [editorial note -- add links] > > I want the @alt to be mandatory for critical content for conformance for > WCAG 1.0 and also [insert new attribute here] for WCAG 2.0. > > That puts accessibility into the right domain. Should the browser still > continue to render pages that don't conform, yes. Should authors right > better code and mark-up content in a proper way, yes. Should the browser > not render a page that is not proper or does not conform? No. > > Cheers > > Josh > > > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080205/d637ccdf/attachment-0001.html From foliot at wats.ca Tue Feb 5 10:33:42 2008 From: foliot at wats.ca (John Foliot) Date: Tue, 5 Feb 2008 10:33:42 -0800 Subject: [html4all] ALT issue redux In-Reply-To: <47A7AB17.2060807@splintered.co.uk> Message-ID: <008001c86825$a29bb050$242e42ab@stanford.edu> Patrick H. Lauke wrote: > It is backwards compatible because valid XHTML1 will always also be > valid HTML5. Also, browsers that currently support XHTML1 won't choke > on missing @alt. Backwards compatibility (and the "two serialisations" > thing) doesn't mean that HTML5 can simply be converted down to XHTML1 > (in which case making a mandatory attribute optional *would* be a > breach). > > I'm not defending the decision to make @alt optional, mind...just > working out the logic that lets HTML WG do it while still following > the backwards-compatibility principle. > Gotcha - thanks Patrick. Still feels regressive to me... From faulkner.steve at gmail.com Thu Feb 7 03:38:13 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Thu, 7 Feb 2008 11:38:13 +0000 Subject: [html4all] alt in HTML5 Required? - to be or not to be Message-ID: <55687cf80802070338v114f34e8m47a2136f9785d8d9@mail.gmail.com> Hi all, have just published a quick post to bring attention to the response from the PFWG alt in HTML5 Required? - to be or not to be -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080207/d1c9d4bf/attachment.html From faulkner.steve at gmail.com Thu Feb 7 07:21:50 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Thu, 7 Feb 2008 15:21:50 +0000 Subject: [html4all] alt issue raised on HTML issue tracker Message-ID: <55687cf80802070721s1759b7cfw1ab41d4dde9e91bb@mail.gmail.com> for those who may miss it: http://www.w3.org/html/wg/tracker/issues/31 interesting to note the langauage used in the description in the issue tracker "The HTML 5 draft allows images without the alt attribute in certain situations. It is unclear what the net accessibility implications of this would be. It has also been suggested that the conformance requirements here should be dictated by WCAG." as against the langauge in the response from the PFWG "barring the introduction of new, good reasons for a change, the failure of the HTML5 draft to make @alt on an across-the-board requirement (even if sometimes it has the value of "") is a bug." "WCAG WG is chartered to set Accessibility guidelines and HTML WG is not; so HTML5 should be careful to create features that support WCAG and describe their use in ways that conform to WCAG." -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080207/062e49b8/attachment.html From joshue.oconnor at cfit.ie Thu Feb 7 07:31:55 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Thu, 07 Feb 2008 15:31:55 +0000 Subject: [html4all] alt issue raised on HTML issue tracker In-Reply-To: <55687cf80802070721s1759b7cfw1ab41d4dde9e91bb@mail.gmail.com> References: <55687cf80802070721s1759b7cfw1ab41d4dde9e91bb@mail.gmail.com> Message-ID: <47AB246B.700@cfit.ie> Steven Faulkner wrote: > for those who may miss it: > http://www.w3.org/html/wg/tracker/issues/31 Good stuff Steve and thanks also to Laura for bringing this up as an issue. I also with to bring @summary up as an issue when the time is right. Cheers Josh From foliot at wats.ca Thu Feb 7 08:23:37 2008 From: foliot at wats.ca (John Foliot) Date: Thu, 7 Feb 2008 08:23:37 -0800 Subject: [html4all] alt issue raised on HTML issue tracker In-Reply-To: <47AB246B.700@cfit.ie> Message-ID: <016f01c869a5$cee7b0b0$1a3c42ab@stanford.edu> Joshue O Connor wrote: > Steven Faulkner wrote: >> for those who may miss it: >> http://www.w3.org/html/wg/tracker/issues/31 > > Good stuff Steve and thanks also to Laura for bringing this up as an > issue. I also with to bring @summary up as an issue when the time is > right. > The time is now . With the first response formally posted by PFWG, it's time we feed them a new one, and summary is as good as any other of our concerns. I think we need to also apply ourselves to @headers/@id for complex tables, but either would be a good second salvo. JF From faulkner.steve at gmail.com Thu Feb 7 08:51:21 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Thu, 7 Feb 2008 16:51:21 +0000 Subject: [html4all] alt issue raised on HTML issue tracker In-Reply-To: <016f01c869a5$cee7b0b0$1a3c42ab@stanford.edu> References: <47AB246B.700@cfit.ie> <016f01c869a5$cee7b0b0$1a3c42ab@stanford.edu> Message-ID: <55687cf80802070851k23629f47o5b4d0e878027f3cb@mail.gmail.com> Hi John, I am glad the PFWG has responded to the alt issue, but i don't think that the tone you are using is useful or productive (even in jest), we need to be working with the other members of the working group not throwing "salvos". In regards to the id/headers issue one thing i picked up from the face2face is that j graham and ben have been doing some great work on making the tables algorithm work much better so that in many cases (note i say many not all) the use of id/headers will not be needed. That is not to say that it should be abandoned and from what i remember j graham and ben thought along similar lines. one of the things that struck me was that it appears (from my understanding of what interrogation features are offered) that screen reader vendors have not even implemented the html4 tables algorithm. On 07/02/2008, John Foliot wrote: > > Joshue O Connor wrote: > > Steven Faulkner wrote: > >> for those who may miss it: > >> http://www.w3.org/html/wg/tracker/issues/31 > > > > Good stuff Steve and thanks also to Laura for bringing this up as an > > issue. I also with to bring @summary up as an issue when the time is > > right. > > > > The time is now . > > With the first response formally posted by PFWG, it's time we feed them a > new one, and summary is as good as any other of our concerns. I think we > need to also apply ourselves to @headers/@id for complex tables, but > either > would be a good second salvo. > > JF > > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080207/0ecabb33/attachment.html From foliot at wats.ca Thu Feb 7 10:12:39 2008 From: foliot at wats.ca (John Foliot) Date: Thu, 7 Feb 2008 10:12:39 -0800 Subject: [html4all] alt issue raised on HTML issue tracker In-Reply-To: <55687cf80802070851k23629f47o5b4d0e878027f3cb@mail.gmail.com> Message-ID: <01b301c869b5$064855a0$1a3c42ab@stanford.edu> Steven Faulkner wrote: > Hi John, > > I am glad the PFWG has responded to the alt issue, but I don't think > that the tone you are using is useful or productive (even in jest), > we need to be working with the other members of the working group not > throwing "salvos". Steven, I agree with your assessment - "salvo" is perhaps not the best word to use in public - and I must remember to be mindful of this, but in many ways we *do* need to continue to press at the issues of concern, and with a concerted and focused attention. Now that a formal response has been issued regarding @ALT, I suggest we need to pick up another issue of concern *now* (as in "when the time is right" - Joshue) and focus our attention on that issue, no matter which it might be - and there still remains many outstanding issues. > > In regards to the id/headers issue one thing i picked up from the > face2face is that j graham and ben have been doing some great work on > making the tables algorithm work much better so that in many cases > (note i say many not all) the use of id/headers will not be needed. > That is not to say that it should be abandoned and from what i > remember j graham and ben thought along similar lines. > one of the things that struck me was that it appears (from my > understanding of what interrogation features are offered) that screen > reader vendors have not even implemented the html4 tables algorithm. Steven, it is that distinction between "many" and "not all" that is the issue. I believe that a strong enough case has been put forward so far to preserve @headers/@id in complex tables that it should be advanced to the PFWG. There was a recent posting regarding empirical need at the governmental level (which I cannot put my hands on at this moment), and in the absence of a better solution for complex tables, I prefer even imperfect A.T. support today vs. a void in the ability to mark up the content appropriately. There is no debate that @headers/@id will generally be of edge-case use/need, but that is not the issue; rather the very fact that they serve a useful and unique purpose in accommodation should be sufficient enough to preserve them in HTML5. I have previously stated that I am quite happy that @scope is not only being preserved, but advocated within HTML5 - this is a positive re-enforcement of an accessibility construct that all developers should be aware of. But that should not be reason to walk away from @headers/@id. And so whether it is the topic of @headers/@id, or of @summary, or [take-your-pick], I suggest that we take up another of our concerns in a coordinated effort, and move it forward via the formal process afford us via W3C WAI PFWG. And if the colloquial use of "salvo" is counter-productive to the discussion, then I apologize for any lack of sensitivity on my part. JF From joshue.oconnor at cfit.ie Thu Feb 7 10:53:58 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Thu, 07 Feb 2008 18:53:58 +0000 Subject: [html4all] alt issue raised on HTML issue tracker In-Reply-To: <01b301c869b5$064855a0$1a3c42ab@stanford.edu> References: <01b301c869b5$064855a0$1a3c42ab@stanford.edu> Message-ID: <47AB53C6.1000002@cfit.ie> I would rather wait a little before I get into @summary and @header/id. There are a few reasons for this. Time constraints being one, and also the fact that these issues have been discussed to a greater or lesser degree. I do however want to raise it as a formal issue on the issue tracker with in the group (if it's not already) but am just waiting a little. It is also important that we also don't underestimate our colleagues within these groups. Many of them are very aware of the issues that are relevant to accessibility and I think we all want to make the spec the best it can be - and we should therefore co-operate the best we can. This is the spirit in which is safest to approach these issues for all concerned. I am glad to see Al GIlmans response to the @alt issue as I see is as positive and that he is considering many perspectives. I also trust there will be a satisfactory outcome. I am applying the same reasoning to my approach with any other issues. My 2 cents. Josh From joshue.oconnor at cfit.ie Thu Feb 7 11:23:40 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Thu, 07 Feb 2008 19:23:40 +0000 Subject: [html4all] request for @summary issue to be raised on HTML issue tracker In-Reply-To: <47AB246B.700@cfit.ie> References: <55687cf80802070721s1759b7cfw1ab41d4dde9e91bb@mail.gmail.com> <47AB246B.700@cfit.ie> Message-ID: <47AB5ABC.3020307@cfit.ie> I have completely changes my mind and requested that the @summary issue be raised on the issue tracker. I will now step away from the keyboard. Cheers Josh From faulkner.steve at gmail.com Fri Feb 8 00:46:41 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Fri, 8 Feb 2008 08:46:41 +0000 Subject: [html4all] How will the response from the pfwg on alt be dealt with? Message-ID: <55687cf80802080046oe559805kb8d30b3137a7135f@mail.gmail.com> Hi Dan, As the PFWG have provided a response to the question of whether alt should be required or optional in HTML5, what is the process for dealing with it within the HTML working group? -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080208/81d8b006/attachment.html From faulkner.steve at gmail.com Fri Feb 8 10:20:42 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Fri, 8 Feb 2008 18:20:42 +0000 Subject: [html4all] How will the response from the pfwg on alt be dealt with? In-Reply-To: <47AC96D2.8050203@w3.org> References: <55687cf80802080046oe559805kb8d30b3137a7135f@mail.gmail.com> <47AC96D2.8050203@w3.org> Message-ID: <55687cf80802081020na5fb4e7wd5e271648d456108@mail.gmail.com> thanks Dan the response was posted to the HTML WG list on the 6th of feb 1. By the principles, HTML5 wants to support accessibility 2. By their charters, WAI groups (here WCAG) are the go-to experts in matters of accessibility 3. WCAG requires @alt (WCAG1) or the function that in HTML4 is provided by @alt (WCAG2) [editorial note -- add links] 4. By the principles, if it ain't broke, don't fix it. 5. Conclusion: barring the introduction of new, good reasons for a change, the failure of the HTML5 draft to make @alt on an across-the-board requirement (even if sometimes it has the value of "") is a bug. http://lists.w3.org/Archives/Public/public-html/2008Feb/0082.html j graham added it to the issue tracker, though from the wording in the description isn't clear that it is about the PFWG response. It would be good to be able to clarify and add relevant info into the tracker on the issue. on that topic, who can add issues to the tracker and what are the criteria for addition? On 08/02/2008, Dan Connolly wrote: > > Steven Faulkner wrote: > > Hi Dan, > > > > As the PFWG have provided a response to the question of whether alt > > should be required or optional in HTML5, what is the process for dealing > > with it within the HTML working group? > > I'm not sure; if you give me a pointer to the PFWG response, that > will help me figure it out. > > This sounds like a design issue; our process around those is not > very mature, though you might make sure it's in the list: > > Product HTML 5 spec > Open and Raised Issues > http://www.w3.org/html/wg/tracker/products/1 > > Our priority is on requirements issues so far: > > Product HTML Principles/Requirements > Open and Raised Issues > http://www.w3.org/html/wg/tracker/products/2 > > We actually made a WG decision on one of the requirements > issues: > > ISSUE-15 > immediate-mode-graphics > requirement for Immediate Mode Graphics and canvas element > http://www.w3.org/html/wg/tracker/issues/15 > > -- > Dan Connolly, W3C http://www.w3.org/People/Connolly/ > > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080208/9ec88e6a/attachment.html From faulkner.steve at gmail.com Fri Feb 22 08:02:10 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Fri, 22 Feb 2008 16:02:10 +0000 Subject: [html4all] alt in HTML5 - Moving Forward Message-ID: <55687cf80802220802v78c28d96xd9412d9a691e4442@mail.gmail.com> I have written a short post about the latest activities in relation to alt issue - alt in HTML5 - Moving Forward -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080222/1947d1f1/attachment.html From P.Taylor at Rhul.Ac.Uk Tue Feb 26 08:44:44 2008 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor (Webmaster)) Date: Tue, 26 Feb 2008 16:44:44 +0000 Subject: [html4all] WG Process Message-ID: <47C441FC.1020106@Rhul.Ac.Uk> Once again, we gain an insight into how "WG Process" is interpreted by one of the HTML 5 editors : > Date: Tue, 26 Feb 2008 04:29:19 +0000 (UTC) > From: Ian Hickson > Executive summary: > > * Tentatively added
    to make reverse lists. We'll remove it > if browser vendors don't like it. Not "if the WG don't approve"; not "if consensus does not emerge", just simply "if browser vendors don't like it". I think I'm going to pull out of the HTML 5 WG completely; the whole exercise is, to my mind, simply degenerating into a farce, and is not something with which I'd like to be associated by those unfortunate enough to inherit the mess. ** Phil. From laura.lee.carlson at gmail.com Tue Feb 26 10:29:05 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Tue, 26 Feb 2008 12:29:05 -0600 Subject: [html4all] WG Process In-Reply-To: <47C441FC.1020106@Rhul.Ac.Uk> References: <47C441FC.1020106@Rhul.Ac.Uk> Message-ID: <1c8dbcaa0802261029q2a20466exffdbf5a4a941d6a9@mail.gmail.com> Hi Phil, > I think I'm going to pull out of the HTML 5 WG > completely; the whole exercise is, to my mind, > simply degenerating into a farce, and is not > something with which I'd like to be associated > by those unfortunate enough to inherit the mess. I have had similar feelings. But when Dan okayed the action item at last week's teleconference to "draft text for HTML 5 spec to require producers/authors to include @alt on img elements", I became more hopeful. http://www.w3.org/html/wg/tracker/actions/54 Jason gave some very sound advice about W3C process and participating in the Working Group. If possible, give it a try. It certainly helped with alt. Best Regards, Laura From P.Taylor at Rhul.Ac.Uk Tue Feb 26 10:38:41 2008 From: P.Taylor at Rhul.Ac.Uk (Philip Taylor (Webmaster)) Date: Tue, 26 Feb 2008 18:38:41 +0000 Subject: [html4all] WG Process In-Reply-To: <1c8dbcaa0802261029q2a20466exffdbf5a4a941d6a9@mail.gmail.com> References: <47C441FC.1020106@Rhul.Ac.Uk> <1c8dbcaa0802261029q2a20466exffdbf5a4a941d6a9@mail.gmail.com> Message-ID: <47C45CB1.5050309@Rhul.Ac.Uk> Laura Carlson wrote: > I have had similar feelings. But when Dan okayed the action item at > last week's teleconference to "draft text for HTML 5 spec to require > producers/authors to include @alt on img elements", I became more > hopeful. > http://www.w3.org/html/wg/tracker/actions/54 > > Jason gave some very sound advice about W3C process and participating > in the Working Group. If possible, give it a try. It certainly helped > with alt. Hmmm. The problem (as I perceive it) is that the joint Chairmen simply aren't (I was going to write "doing their job", but that is both perjorative and possibly even libellous) exerting anywhere near influence over the activities of the editors. We still have Ian cross-posting to three groups, whilst asking all concerned to respond to only one (thereby ensuring that 66% see only Ian's contributions rather than those of other members of the group), stating in public that he will decide what stays and what goes based solely on the reactions of browser vendors, and so on. If Dan et al can't/won't control the editors, what chance do the rest of us stand ? ** Phil. From laura.lee.carlson at gmail.com Tue Feb 26 10:59:49 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Tue, 26 Feb 2008 12:59:49 -0600 Subject: [html4all] WG Process In-Reply-To: <47C45CB1.5050309@Rhul.Ac.Uk> References: <47C441FC.1020106@Rhul.Ac.Uk> <1c8dbcaa0802261029q2a20466exffdbf5a4a941d6a9@mail.gmail.com> <47C45CB1.5050309@Rhul.Ac.Uk> Message-ID: <1c8dbcaa0802261059p6c5eb5fcgb6f783062a909a37@mail.gmail.com> Hi Phil, > exerting anywhere near > influence over the activities of the editors. The rewrite of the alt section by Steve, et al may be the test of this. The outcome will reveal if the current process can work. Best Regards, Laura From chaals at opera.com Tue Feb 26 12:05:23 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Tue, 26 Feb 2008 21:05:23 +0100 Subject: [html4all] WG Process In-Reply-To: <47C441FC.1020106@Rhul.Ac.Uk> References: <47C441FC.1020106@Rhul.Ac.Uk> Message-ID: On Tue, 26 Feb 2008 17:44:44 +0100, Philip Taylor (Webmaster) wrote: > Once again, we gain an insight into how "WG Process" > is interpreted by one of the HTML 5 editors : > >> Date: Tue, 26 Feb 2008 04:29:19 +0000 (UTC) >> From: Ian Hickson > >> Executive summary: >> >> * Tentatively added
      to make reverse lists. We'll remove >> it >> if browser vendors don't like it. > > Not "if the WG don't approve"; not "if consensus > does not emerge", just simply "if browser vendors > don't like it". Maybe as a browser vendor people don't think much of my opinion, but with that disclaimer made... Ian (and Dave, if he were actually editing rather than apparently being a fictional character as far as the spec goes) are effectively free to edit how they like until there is a working group decision. Ian's approach is basically that he thinks the browser makers are the most critical part of the chain, because if they don't implement then the spec is worthless anyway. I have a lot of sympathy for that position - if you don't have implementation, you're writing fantasy, not a standard. On the other hand the browser makers (and particularly if you only mean 4 desktop browser makers rather than the dozens who are out there) are only one group of stakeholders - people who create authoring tools like Dreamweaver, Word, and various Content management systems are at least as important since browsers have to do something with what those systems produce (and always compete on how well they do that), and content producers large and small have things they need to put online and will put on in the best way they find, so their input is important too (although a large content producer or a solid bloc of content producers is more convincing than a handful of people on their own - such is realpolitik). But I have no sympathy for any approach that doesn't make it clear that at the end of the process, the working group is the final arbiter of what the working group produces. In particular, I agree that Ian's approach of asking people to split replies into various different places is counter productive since it means that the input to the decision making process is only clear to people who have time to follow everything Ian does (and as he says he works full-time on it, which is a luxury not enjoyed by the rest of us). > I think I'm going to pull out of the HTML 5 WG > completely; the whole exercise is, to my mind, > simply degenerating into a farce, and is not > something with which I'd like to be associated > by those unfortunate enough to inherit the mess. I think that would be a shame. I don't think the working group is a farce, although I do think the proces is not ideal. On the other hand, an ideal process would require resources that are not available, and I think that what we have is more or less workable. Added to the fact that HTML needs (IMHO) to be one clear spec and isn't going to vanish anyway, I will stick with the working group. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From foliot at wats.ca Tue Feb 26 16:30:08 2008 From: foliot at wats.ca (John Foliot) Date: Tue, 26 Feb 2008 16:30:08 -0800 Subject: [html4all] WG Process In-Reply-To: Message-ID: <00c901c878d7$eaf55eb0$cc2a42ab@stanford.edu> Charles McCathieNevile wrote: >>> From: Ian Hickson >>> Executive summary: >>> >>> * Tentatively added
        to make reverse lists. We'll >>> remove it >>> if browser vendors don't like it. >> > > Maybe as a browser vendor people don't think much of my opinion, but > with that disclaimer made... Actually Chaals, your perspective as both a Browser vendor principle, coupled with your extensive understanding and experience from within W3C is extremely valuable, so thanks for sticking around. > Ian's approach is basically that he thinks the browser makers are the > most critical part of the chain, because if they don't implement then > the spec is worthless anyway. An interesting comment... > > I have a lot of sympathy for that position - if you don't have > implementation, you're writing fantasy, not a standard. On the other > hand the browser makers (and particularly if you only mean 4 desktop > browser makers rather than the dozens who are out there) are only one > group of stakeholders - ... And so returning to the first comment. What happens if Opera and Mozilla think that
          is the be-all and end-all, and WebKit and Redmond say bah, piffle...? While seeking feedback and input from browser vendors is important ("yes, we think we can do this", "no, this is going to be a nightmare to implement"), allowing the tail to continually wag the dog is a dangerous position to be in. Given the above scenario, what happens then? (From far off in the distance of time, John can hear the familiar refrain "Best viewed in...")... Funny, we didn't seem to have the same kind of problems with CSS/ACID 2 now did we? The spec was stated, the gauntlet thrown down (ACID 2 - authored by Ian Hickson no less), and slowly browsers started to work towards passing ACID 2 (including Opera's Presto layout engine and Apple's WebKit engine). Sadly, with HTML5, it doesn't seem to be moving the same way. Instead, we have various pet projects and perceived needs racing though the "system", and with them "bug fixes" being filed, while at the same time we, as content authors and in some cases content consumers are being asked to justify everything we say we need or want. Yes, as Laura stated, having the WG agree to look at a proposed re-write for @ALT lends some encouragement, but what of the other open issues, plus others as and when they emerge? > > In particular, I agree that Ian's approach of asking people to split > replies into various different places is counter productive since it > means that the input to the decision making process is only clear to > people who have time to follow everything Ian does (and as he says he > works full-time on it, which is a luxury not enjoyed by the rest of > us). It also places him at the top as puppet-master, as he can flit back and forth as his mood sees fit. Of all the many complaints *I* have with the current process, this by far is the largest. It amounts to nothing more than divide and conquer in the classic sense. > > I think that would be a shame. I don't think the working group is a > farce, although I do think the proces is not ideal. I think that the further it moves forward, the less credible it becomes every day. With statements such as that attributed to Ian, it could give the casual on-looker the impression that this is instead going to emerge as HTML-hixie (similar too, but not the same as [http://www.whatwg.org/specs/web-apps/current-work/]) JF From laura.lee.carlson at gmail.com Wed Feb 27 08:02:39 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Wed, 27 Feb 2008 10:02:39 -0600 Subject: [html4all] WG Process In-Reply-To: <00c901c878d7$eaf55eb0$cc2a42ab@stanford.edu> References: <00c901c878d7$eaf55eb0$cc2a42ab@stanford.edu> Message-ID: <1c8dbcaa0802270802y3e0ee3c2je6bd33c31cd56408@mail.gmail.com> Chaals wrote: >> Maybe as a browser vendor people don't think much of my opinion John wrote: > Actually Chaals, your perspective as both a Browser vendor principle, > coupled with your extensive understanding and experience from within > W3C is extremely valuable, so thanks for sticking around. I agree one hundred percent with John here. Chaals, your perspective, experience, and advice is precious. Thank you so very much for being here. Phil wrote: >> I think I'm going to pull out of the HTML 5 WG completely I agree one hundred percent with Chaals on this one. That, Phil, would be a shame. A true pity. John wrote: > Yes, as Laura stated, having the WG > agree to look at a proposed re-write for @ALT lends some > encouragement, but what of the other open issues, plus others as and > when they emerge? Hopefully following the issue and process advice that Jason and Chaals outlined [1] will work. As Chaals mentioned the working group hasn't made a decision that requires the editor to do something in terms of the draft yet. So alt will be a good test (probably the first test) to see if the existing system can succeed. Please do try following Jason's and Chaals' issue advise for other issues too. Give it your best. If it doesn't work, having followed Jason's and Chaals' process advise may very well come in handy. Chaals wrote: > Ian's approach is basically that he thinks the browser makers are the > most critical part of the chain, because if they don't implement then > the spec is worthless anyway. This would relate to the "Priority of Constituencies" design principle. It says: "In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once." [2] Best Regards, Laura [1] http://html4all.org/mailman/private/talk_html4all.org/2008-February/thread.html#366 [2] http://www.w3.org/TR/html-design-principles/#priority-of-constituencies From Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org Wed Feb 27 08:20:05 2008 From: Philip-and-LeKhanh at Royal-Tunbridge-Wells.Org (Philip TAYLOR) Date: Wed, 27 Feb 2008 16:20:05 +0000 Subject: [html4all] WG Process In-Reply-To: <1c8dbcaa0802270802y3e0ee3c2je6bd33c31cd56408@mail.gmail.com> References: <00c901c878d7$eaf55eb0$cc2a42ab@stanford.edu> <1c8dbcaa0802270802y3e0ee3c2je6bd33c31cd56408@mail.gmail.com> Message-ID: <47C58DB5.1030001@Royal-Tunbridge-Wells.Org> Laura Carlson wrote: > Chaals wrote: >> Ian's approach is basically that he thinks the browser makers are the >> most critical part of the chain, because if they don't implement then >> the spec is worthless anyway. > > This would relate to the "Priority of Constituencies" design principle. It says: > > "In case of conflict, consider users over authors over implementors > over specifiers over theoretical purity. In other words costs or > difficulties to the user should be given more weight than costs to > authors; which in turn should be given more weight than costs to > implementors; which should be given more weight than costs to authors > of the spec itself, which should be given more weight than those > proposing changes for theoretical reasons alone. Of course, it is > preferred to make things better for multiple constituencies at once." > [2] > > Best Regards, > Laura > [2] http://www.w3.org/TR/html-design-principles/#priority-of-constituencies The problem is (as I see it) that both "we" and "they" cite the /Draft/ Design Principles as if they had been agreed; they have not, and this is (IMHO) one of the greatest weaknesses of the whole process. We debate (some) aspects of the Draft Specification without ever agreeing what our Design Principles are. As a result, there is no coherence, no common goal, just an open forum in which each can cite the "Design Principles" when it suits, and quietly ignore them at other times ... I would like a complete moratorium on any discussion on the Draft Specification, and in its place, a well-led debate (ultimately leading to agreement) on each and every Design Principle in turn (including "Design Principles" that do not even appear as of today). ** Phil. From chaals at opera.com Wed Feb 27 08:28:30 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Wed, 27 Feb 2008 17:28:30 +0100 Subject: [html4all] WG Process In-Reply-To: <1c8dbcaa0802270802y3e0ee3c2je6bd33c31cd56408@mail.gmail.com> References: <00c901c878d7$eaf55eb0$cc2a42ab@stanford.edu> <1c8dbcaa0802270802y3e0ee3c2je6bd33c31cd56408@mail.gmail.com> Message-ID: On Wed, 27 Feb 2008 17:02:39 +0100, Laura Carlson wrote: > Chaals wrote: (inter alia) >> Ian's approach is basically that he thinks the browser makers are the >> most critical part of the chain, because if they don't implement then >> the spec is worthless anyway. > > This would relate to the "Priority of Constituencies" design principle. > It says: > > "In case of conflict, consider users over authors over implementors > over specifiers over theoretical purity..." > [2] Hmmm. Except that in the case mentioned, there is a request from authors, no idea how it works or users (since nobody knows until someone implements it), and so Ian is waiting to see if it gets sufficient love for someone to put the broser code together. Given that the spec really is a draft (and in some cases a very speculative one at that) I don't think this is a bad appraoch - so long as he follows working group decisions, my only complaint is the "divide-and-rule" (as John called it) approach to feedback, which makes it harder for anyone else to follow what the spec does. > [2] > http://www.w3.org/TR/html-design-principles/#priority-of-constituencies cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com From laura.lee.carlson at gmail.com Wed Feb 27 09:23:25 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Wed, 27 Feb 2008 11:23:25 -0600 Subject: [html4all] WG Process In-Reply-To: <47C58DB5.1030001@Royal-Tunbridge-Wells.Org> References: <00c901c878d7$eaf55eb0$cc2a42ab@stanford.edu> <1c8dbcaa0802270802y3e0ee3c2je6bd33c31cd56408@mail.gmail.com> <47C58DB5.1030001@Royal-Tunbridge-Wells.Org> Message-ID: <1c8dbcaa0802270923l4a7463eeiccd4c9dbd15abf55@mail.gmail.com> Hi Phil, > We debate (some) aspects of the Draft Specification > without ever agreeing what our Design Principles > are. Good point. Principles are fundamental value guides used to base decisions. Dan has said, "their main utility is as justification in discussions..." [1]. Yet, as you say the principles are a draft subject to change. > I would like a complete > moratorium on any discussion on the Draft Specification, > and in its place, a well-led debate (ultimately > leading to agreement) on each and every Design > Principle in turn (including "Design Principles" > that do not even appear as of today). Sounds like an issue that you feel strongly about. You may want to raise and try to get action on it by following Jason's and Chaals' advice. BTW Dan also advised to go to teleconferences. He said that "action items are accepted/assigned in teleconference or IRC discussion." [2][3] Best Regards, Laura [1] http://krijnhoetmer.nl/irc-logs/html-wg/20070817#l-43 [2] http://lists.w3.org/Archives/Public/www-archive/2008Feb/0022.html [3] http://lists.w3.org/Archives/Public/www-archive/2008Feb/0027.html