From faulkner.steve at gmail.com Thu May 1 00:09:33 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Thu, 1 May 2008 08:09:33 +0100 Subject: [html4all] HTML5 Alternative Text, and Authoring Tools Message-ID: <55687cf80805010009s9425a87i8a266f601094c7db@mail.gmail.com> HTML5 Alternative Text, and Authoring Tools http://juicystudio.com/article/html5-alt-text-authoring-tools.php -- 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 From faulkner.steve at gmail.com Thu May 1 01:23:46 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Thu, 1 May 2008 09:23:46 +0100 Subject: [html4all] HTML5 Alternative Text, and Authoring Tools In-Reply-To: <55687cf80805010009s9425a87i8a266f601094c7db@mail.gmail.com> References: <55687cf80805010009s9425a87i8a266f601094c7db@mail.gmail.com> Message-ID: <55687cf80805010123n8d29bbx58575676e467fd7f@mail.gmail.com> A section of Ian hickson's comment on "HTML5 Alternative Text, and Authoring Tools": "We truly do believe in research, hard data, and analysis, rather than hypotheticals; and we truly do believe that evidence suggests that what we are arguing for is going to improve the accessibility of the Web." http://juicystudio.com/article/html5-alt-text-authoring-tools.php#comment2 Please show us the evidence. see ya! stevef On 01/05/2008, Steven Faulkner wrote: > HTML5 Alternative Text, and Authoring Tools > http://juicystudio.com/article/html5-alt-text-authoring-tools.php > > -- > 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 > -- 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 From faulkner.steve at gmail.com Thu May 1 05:44:53 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Thu, 1 May 2008 13:44:53 +0100 Subject: [html4all] HTML5 and alt: The editors new clothes Message-ID: <55687cf80805010544v7f22ec55sd748cef83e17e150@mail.gmail.com> HTML5 and alt: The editors new clothes http://www.paciellogroup.com/blog/?p=63 "The HTML5 editor has recently stated in his defence of the alt being optional: "We truly do believe in research, hard data, and analysis, rather than hypotheticals; and we truly do believe that evidence suggests that what we are arguing for is going to improve the accessibility of the Web." Problem is, no "research, hard data, and analysis" has been provided..." -- 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 From oedipus at hicom.net Thu May 1 08:18:33 2008 From: oedipus at hicom.net (Gregory J. Rosmaita) Date: Thu, 1 May 2008 16:18:33 +0100 Subject: [html4all] single abbreviated form fleshed out by rob on wiki In-Reply-To: <20080427180623.M10119@hicom.net> References: <481001F2.4080801@malform.no> <20080424040620.GA22010@jpc.local> <20080427144743.M713@hicom.net> <4331541A-883F-41A7-962D-FAD185F11E15@robburns.com> <20080427162609.M49777@hicom.net> <20080427180623.M10119@hicom.net> Message-ID: <20080501150714.M46452@hicom.net> aloha, rob! i REALLY like the additions you made to the "Single Abbreviated Element" aspect of http://esw.w3.org/topic/HTML/AbbrAndInitialisms i have been searching in vain since the topic re-arose for my proposal for how DFN could be used in conjunction with ABBR to provide a re-use mechanism, and your exposition and investigation of the possibilities are concise, coherent, and cogent -- 3 things i personally have trouble attaining... thank you, rob -- you have a unique skill set that the WG has yet to fully appreciate, but which is greatly appreciated by those of us with whom you've engaged in dialog and discussion are quite cognizant of your superior communication skills and your consensus building approach to collaborative work... and that goes for the rest of y'all too -- it is indeed an honor (if not actually a "pleasure", given the nature of the work) to have such colleagues -- it goes a VERY long way to keeping this pessimist's HTML5 glass half-full! gregory ------------------------------------------------ The optimist thinks that this is the best of all possible worlds; the pessimist knows it is. ------------------------------------------------ Gregory J. Rosmaita: oedipus at hicom.net Camera Obscura: http://www.hicom.net/~oedipus ------------------------------------------------ From foliot at wats.ca Thu May 1 11:25:11 2008 From: foliot at wats.ca (John Foliot) Date: Thu, 1 May 2008 11:25:11 -0700 Subject: [html4all] HTML5 Alternative Text, and Authoring Tools In-Reply-To: <55687cf80805010123n8d29bbx58575676e467fd7f@mail.gmail.com> Message-ID: <006401c8abb8$b16a3940$da3142ab@stanford.edu> Steven Faulkner wrote: > A section of Ian hickson's comment on "HTML5 Alternative Text, and > Authoring Tools": > > "We truly do believe in research, hard data, and analysis, rather > than hypotheticals; and we truly do believe that evidence suggests > that what we are arguing for is going to improve the accessibility of > the Web." > > http://juicystudio.com/article/html5-alt-text-authoring-tools.php#comment2 > > > Please show us the evidence. I have been asking for 'evidence' since September of 2007: [http://lists.w3.org/Archives/Public/www-archive/2007Sep/0019.html] JF From faulkner.steve at gmail.com Thu May 1 11:45:36 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Thu, 1 May 2008 19:45:36 +0100 Subject: [html4all] HTML5 Alternative Text, and Authoring Tools In-Reply-To: References: <006401c8abb8$b16a3940$da3142ab@stanford.edu> Message-ID: <55687cf80805011145n245a7b7cl28b67fa9c4905689@mail.gmail.com> ian hickson wrote: > It's not clear exactly what evidence is being requested. The reasoning for > the current text has been the subject of a number of long and detailed > e-mails to these lists already. but no "research, hard data, and analysis" refer to: http://www.paciellogroup.com/blog/?p=63 see ya! On 01/05/2008, Ian Hickson wrote: > > On Thu, 1 May 2008, John Foliot wrote: > > Steven Faulkner wrote: > > > A section of Ian hickson's comment on "HTML5 Alternative Text, and > > > Authoring Tools": > > > > > > "We truly do believe in research, hard data, and analysis, rather > > > than hypotheticals; and we truly do believe that evidence suggests > > > that what we are arguing for is going to improve the accessibility of > > > the Web." > > > > > > http://juicystudio.com/article/html5-alt-text-authoring-tools.php#comment2 > > > > > > Please show us the evidence. > > It's not clear exactly what evidence is being requested. The reasoning for > the current text has been the subject of a number of long and detailed > e-mails to these lists already. > > > > I have been asking for 'evidence' since September of 2007: > > [http://lists.w3.org/Archives/Public/www-archive/2007Sep/0019.html] > > I replied to that e-mail in detail within hours: > > http://lists.w3.org/Archives/Public/www-archive/2007Sep/0020.html > > I notice you never followed up. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > > -- 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 From foliot at wats.ca Thu May 1 12:54:23 2008 From: foliot at wats.ca (John Foliot) Date: Thu, 1 May 2008 12:54:23 -0700 Subject: [html4all] HTML5 Alternative Text, and Authoring Tools In-Reply-To: Message-ID: <007a01c8abc5$27a98ff0$da3142ab@stanford.edu> Ian Hickson wrote: > On Thu, 1 May 2008, John Foliot wrote: >> Steven Faulkner wrote: >>> A section of Ian hickson's comment on "HTML5 Alternative Text, and >>> Authoring Tools": >>> >>> "We truly do believe in research, hard data, and analysis, rather >>> than hypotheticals; and we truly do believe that evidence suggests >>> that what we are arguing for is going to improve the accessibility >>> of the Web." >>> >>> http://juicystudio.com/article/html5-alt-text-authoring-tools.php#co >>> mment2 >>> >>> Please show us the evidence. > > It's not clear exactly what evidence is being requested. * Substantiated "proof" that your opinion and claim has more legitimacy than the authoritative advise of the PFWG who specifically recommended that @alt remain mandatory would be a good start. * Evidence that you understand that @alt supports more than just users of screen voicing technology: [ih]"My claim is based on the concept that a user only needs to hear information once, not twice." http://lists.w3.org/Archives/Public/www-archive/2007Sep/0020.html [ih] "And if _you_, an accessibility expert who cares about blind people, don't bother to include descriptions of photos you upload to Flickr, how can we possibly expect Random Joe User, who frankly _doesn't_ care about blind users, to write descriptions for Flickr to include?" http://lists.w3.org/Archives/Public/public-html/2008Apr/0434.html > The > reasoning for the current text has been the subject of a number of > long and detailed e-mails to these lists already. Where you and your supporters have continued to espouse your opinion with no more factual data than what we, your detractors, have provided. It is true, both sides have argued as much from "gut" as it has from evidence, but given that one side is, by W3C recognition, the experts on accessibility (PFWG) and the other side is the authors of a Spec (HTML WG) most reasonable observers *could* reach the conclusion that the accessibility experts do have the upper hand. So once again Ian please point us to any survey, study, white-paper or other external evidence that **proves** your opinion has more credence than those of your detractors. Please give us the name of one single, recognized web accessibility authority who has, or can, substantiate your claims. In previous emails I have given you any number of recognizable names whom I would accept as being authorities - so it's not like there is nobody to specifically question. There *are* however numerous such authorities questioning your assertions already, and others who are notably absent from any discussion surrounding this issue (why is that?). That's the kind of evidence requested. (FWIW, the one expert source who *has* spoken to the issue - the PFWG - have recommended to maintain @alt as mandatory, and you specifically, arrogantly, ignore this guidance.) Ian, you might have a ton of experience at Specification authoring/editing, but time and time again, your colloquial reference to accessibility issues (and the dogged insistence on thinking of @alt as a "blind" issue) speaks volumes on your real understanding and experience with accessibility issues. There is no doubt you are sincere in your desire to improve web accessibility, but honestly you can't be an expert on everything, and in this area, you are clearly not an expert. > > >> I have been asking for 'evidence' since September of 2007: >> [http://lists.w3.org/Archives/Public/www-archive/2007Sep/0019.html] > > I replied to that e-mail in detail within hours: > > http://lists.w3.org/Archives/Public/www-archive/2007Sep/0020.html > > I notice you never followed up. You're kidding right? I have spent hours, quite literally, writing and responding to emails on this topic - if that particular thread was dropped, it's not like I fell off the face of the earth. A search of the W3C archives can attest to the fact that I have continued to monitor and comment on the @alt attribute within HTML5 since that September 2007 posting. Along the way, I've even come part way to accepting that a mandatory @alt may indeed be less than useful, although not for any of the reasons that you suggest in the current Draft (those reasons being bull feathers). Earlier this week I even provided some specific concrete suggestions in an effort to further the discussion beyond "is so/is not", to which no-one has really commented on way or the other: [http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/0393.html] So outside of you perfunctorily announcing that you had examined the outstanding emails surrounding this issue, and could find no other reason to reverse your decision to maintain @alt as optional in some instances, what substantive value have _you_ contributed to this discussion in the past 2 weeks? JF From faulkner.steve at gmail.com Thu May 1 13:10:43 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Thu, 1 May 2008 21:10:43 +0100 Subject: [html4all] HTML5 Alternative Text, and Authoring Tools In-Reply-To: References: <006401c8abb8$b16a3940$da3142ab@stanford.edu> <55687cf80805011145n245a7b7cl28b67fa9c4905689@mail.gmail.com> Message-ID: <55687cf80805011310n22f3759en576b031c65d341e6@mail.gmail.com> ian hickson wrote: >There has been plenty of research and analysis. As far as hard data is >concerned, it would indeed be nice if we could get more data. Once again if so where is it, where is the research?? Where is the properly conducted research which shows that making the alt optional will lead to accessibility benefits as you [1] claim?? Show us the the proof Ian. I have made it clear what is required from you [2], it is not incumbent on anybody but you to back up your claims. Currently you provide nothing more than your opinion as a basis for making the alt optional in the spec. The HTML working group deserves more than this. see ya! [1] http://juicystudio.com/article/html5-alt-text-authoring-tools.php#comment2 [2] http://www.paciellogroup.com/blog/?p=63 2008/5/1 Ian Hickson : > On Thu, 1 May 2008, Steven Faulkner wrote: > > > > ian hickson wrote: > > > It's not clear exactly what evidence is being requested. The reasoning for > > > the current text has been the subject of a number of long and detailed > > > e-mails to these lists already. > > > > but no "research, hard data, and analysis" > > refer to: > > http://www.paciellogroup.com/blog/?p=63 > > There has been plenty of research and analysis. As far as hard data is > concerned, it would indeed be nice if we could get more data. James > started work in this area: > > http://esw.w3.org/topic/HTML/AltSurvey > > I have volunteered to help out (I can provide the random sample of URLs) > but we need more people -- can you help? > > -- > > > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- 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 From foliot at wats.ca Thu May 1 16:33:57 2008 From: foliot at wats.ca (John Foliot) Date: Thu, 1 May 2008 16:33:57 -0700 Subject: [html4all] HTML5 Alternative Text, and Authoring Tools In-Reply-To: <481A3D18.7000302@cam.ac.uk> Message-ID: <00a701c8abe3$d3e70e00$da3142ab@stanford.edu> James Graham wrote: > I should just point out that *no one* has presented > data from a useful alt study yet. That applies equally to people who > believe the balance of arguments weigh in favour of allowing alt to be > omitted where no reasonable alt test is available /and/ those who > believe it must always be present in conforming documents. Agreed. As Steven Faulkner has pointed out, we require a "...proper scientific study that is based on scientific method." [http://www.paciellogroup.com/blog/?p=63] However in absence of such study, the mandatory requirement for @alt currently exists within HTML 4.01 as well as XHTML 1.0, and the editor's decision to reverse precedent and remove this requirement has not been substantially proven to be the right solution. More-over, the W3C body entrusted to make decisions and recommendations regarding "web accessibility" has come forward with the official position of maintaining the status quo, and continue to insist on the mandatory inclusion of @alt: " 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] While the editor claims in fact that there are "new, good reasons", he has not been able to successfully prove that they are good, never-mind reasons (this requires proof), and are in fact seen by many as simply excuses to forgive poor authoring tools/authoring environments. Thus, in light of current fact, I would suggest that the editor is wrong here, and must revisit the Draft, rather than attempt to close this item as "resolved" as currently written (which is what he tried to do). [http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/0030.html] > Furthermore there is no reason that people with one of these opinions > needs to provide data whilst people with the other opinion do not. In > particular there is no reason to believe that because something was in > HTML 4 or is in some other spec it should be subject to less scrutiny > than new ideas. There is no argument here, however what has happened is that the editor has unilaterally made a change - embraced a new idea - without proving that the new idea is better than the old. Experts in the field have questioned this move, and have asked for specific proof that the new idea is indeed better, and this proof has not come forward. Given that one of the design principles of HTML5 is "...if it ain't broke, don't fix it", and the editor is allegedly "fixing" something, then proof that it is indeed broken should be required, and it should be delivered by the person making this claim - the editor. The current justifications in the Draft do not stand up to scrutiny by the experts - they are excuses for one or more contributors not fulfilling their responsibility, but not technically "impossible" scenarios to address: they confuse "won't" with "can't". Further, as I continue to point out, the final arbitrator of conformance is left to the content creator's "honor system" - it cannot be measured by mechanical means alone - which is not how/what a Standard should be. I for one do not question the basic premise of the assertion - in fact I am starting to come to terms with it - but the simple fact is that the proposed "solution" has emerged, not from the expert community or from study or survey, but rather from internal discussions between a small group of authors and the editor (the now infamous HTML5 cabal), none of whom are of the "official" community of expertise (W3C PFWG) or even recognized as expert from within the larger community. I have repeatedly asked for a recognizable name from within the accessibility field with whom they have consulted, and have even suggested names of people with whom they might consult, but have never been answered. It is for *this* reason that the burden-of-proof rests with the editor to prove his position. > Lastly, I do not understand why it is perceived as the responsibility > of the editor to do any study that other members of the group feel is > required. That expectation will not scale. It is the responsibility of the editor to listen to the groups chartered by the W3C as "expert", and accept their guidance unless the editor can prove that those recommendations are wrong, which requires study and proof. If Ian Hickson wishes to ignore the specific recommendation of the W3C PFWG (who reached their position based on internal discussion and consensus), then yes, it is his responsibility to provide justification and proof for directly going against this recommendation - why should it not be? I personally believe that if we are to truly examine the issue, then both sides must be prepared to abandon entrenched ideas and have an open mind. I also believe that I am pretty much there, and have floated some alternative ideas - again, untested ideas, but possibilities beyond what we have now. Finally I suggest that the thoughts of Al Gilman are apropos and should be required reading by both sides of this discussion. [http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/0367.html] However, the basic fact remains: the editor must prove that the officially recognized experts are wrong, and not just say that they are. JF From faulkner.steve at gmail.com Thu May 1 20:22:29 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Fri, 2 May 2008 04:22:29 +0100 Subject: [html4all] HTML5 Alternative Text, and Authoring Tools In-Reply-To: <481A3D18.7000302@cam.ac.uk> References: <006401c8abb8$b16a3940$da3142ab@stanford.edu> <55687cf80805011145n245a7b7cl28b67fa9c4905689@mail.gmail.com> <55687cf80805011310n22f3759en576b031c65d341e6@mail.gmail.com> <481A3D18.7000302@cam.ac.uk> Message-ID: <55687cf80805012022h4da0dd92g9df86d4a543c474e@mail.gmail.com> jgraham wrote: >I should just point out that *no one* has presented data from a useful alt > study yet. So statements[1] by the editor about the "evidence" suggesting that making the alt optional "is going to improve the accessibility of the Web" are duplicitous "We truly do believe in research, hard data, and analysis, rather than hypotheticals; and we truly do believe that evidence suggests that what we are arguing for is going to improve the accessibility of the Web." [1] http://juicystudio.com/article/html5-alt-text-authoring-tools.php#comment3 > Lastly, I do not understand why it is perceived as the responsibility of > the editor to do any study that other members of the group feel is required. Simply because he has claimed that his decision in the spec about the alt is based on research "rather than hypotheticals". regards stevef 2008/5/1 James Graham : > Steven Faulkner wrote: > > > > I have made it clear what is required from you [2], it is not > > incumbent on anybody but you to back up your claims. Currently you > > provide nothing more than your opinion as a basis for making the alt > > optional in the spec. The HTML working group deserves more than this. > > > > Whilst I fear to reply to this thread for worry it will create an avalanche > of emails that could suck up time that could be more productively used, I > should just point out that *no one* has presented data from a useful alt > study yet. That applies equally to people who believe the balance of > arguments weigh in favour of allowing alt to be omitted where no reasonable > alt test is avaliable /and/ those who believe it must always be present in > conforming documents. > > Furthermore there is no reason that people with one of these opinions needs > to provide data whilst people with the other opinion do not. In particular > there is no reason to believe that because something was in HTML 4 or is in > some other spec it should be subject to less scrutiny than new ideas. > > Lastly, I do not understand why it is perceived as the responsibility of > the editor to do any study that other members of the group feel is required. > That expectation will not scale. > > -- > "Mixed up signals > Bullet train > People snuffed out in the brutal rain" > --Conner Oberst > -- 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 From faulkner.steve at gmail.com Fri May 2 10:57:38 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Fri, 2 May 2008 18:57:38 +0100 Subject: [html4all] failure to follow through is not evidence of intent to deceive [was: Re: HTML5 Alternative Text, and Authoring Tools] In-Reply-To: <9A3F0B4E-F6C1-4533-A94F-B9219710AB6D@IEEE.org> References: <006401c8abb8$b16a3940$da3142ab@stanford.edu> <55687cf80805011145n245a7b7cl28b67fa9c4905689@mail.gmail.com> <55687cf80805011310n22f3759en576b031c65d341e6@mail.gmail.com> <481A3D18.7000302@cam.ac.uk> <55687cf80805012022h4da0dd92g9df86d4a543c474e@mail.gmail.com> <9A3F0B4E-F6C1-4533-A94F-B9219710AB6D@IEEE.org> Message-ID: <55687cf80805021057te8eea9ayeb2b49c33f304b91@mail.gmail.com> Hi Al, I apologise and retract my statement about Ian's duplicity, in relation to this matter. Consider it an act of folly, born out of frustration with what I perceive as the intransigence, with which proposals in relation to accessibility in HTML5 ,are often met with. People in the HTML working group that have questioned the decisions of the editor in the past, have often times been asked to provide research based evidence. Calling on editor to do the same, is what we would consider in Australia as the requirement for a "level playing field"[1]. [1]http://www.phrases.org.uk/meanings/228650.html best regards stevef 2008/5/2 Al Gilman : > > On 1 May 2008, at 11:22 PM, Steven Faulkner wrote: > > > > jgraham wrote: > > > > > I should just point out that *no one* has presented data from a useful > alt > > > study yet. > > > > > > > So statements[1] by the editor about the "evidence" suggesting that > > making the alt optional "is going to improve the accessibility of the > > Web" are duplicitous > > > > Whoa! I see no evidence of intent to deceive, > > http://www.merriam-webster.com/dictionary/duplicitous > > or that Ian doesn't believe all that he said. > > > > "We truly do believe in research, hard data, and analysis, rather > > than hypotheticals; and we truly do believe that evidence suggests > > that what we are arguing for is going to improve the accessibility of > > the Web." > > [1] > http://juicystudio.com/article/html5-alt-text-authoring-tools.php#comment3 > > > > > > > Lastly, I do not understand why it is perceived as the responsibility > of > > > the editor to do any study that other members of the group feel is > required. > > > > > > > Simply because he has claimed that his decision in the spec about the > > alt is based on research "rather than hypotheticals". > > > > There is no responsibility to *do a study* that falls peculiarly on any one > party. On the other hand, the "social competence" that the W3C Process > asks of Participants > > > http://www.w3.org/2005/10/Process-20051014/policies.html#ParticipationCriteria > > should be interpreted as: > > > > If you believe there is evidence supporting your conclusion, share the > > evidence and not just the conclusion. > > > > > A corollary would seem to be "If you can't share the evidence, don't > claim the authority of evidence." > > There would appear to be a missed opportunity to exercise leadership, > in this regard. > > Let's practice "I statements" so Ian can say "my experience leaves me > thinking this" and Steve can say "my experience leaves me thinking that" > and we can recognize that there are varieties of experience that have > contributed to varieties of interpretation. > > "let's get some evidence that we can all believe > in" is, while hypthetical as stated, a pointer to one way out of the > existing situation where different people's experience has led them to > differing interpretations. Maybe we can all agree it would help, even > if none of us has an instantly-ready-to-offer capability to conduct > fresh research. > > Al > > > > regards > > stevef > > > > > > 2008/5/1 James Graham : > > > > > Steven Faulkner wrote: > > > > > > > > > > > > > I have made it clear what is required from you [2], it is not > > > > incumbent on anybody but you to back up your claims. Currently you > > > > provide nothing more than your opinion as a basis for making the alt > > > > optional in the spec. The HTML working group deserves more than this. > > > > > > > > > > > > > > Whilst I fear to reply to this thread for worry it will create an > avalanche > > > of emails that could suck up time that could be more productively used, > I > > > should just point out that *no one* has presented data from a useful alt > > > study yet. That applies equally to people who believe the balance of > > > arguments weigh in favour of allowing alt to be omitted where no > reasonable > > > alt test is avaliable /and/ those who believe it must always be present > in > > > conforming documents. > > > > > > Furthermore there is no reason that people with one of these opinions > needs > > > to provide data whilst people with the other opinion do not. In > particular > > > there is no reason to believe that because something was in HTML 4 or is > in > > > some other spec it should be subject to less scrutiny than new ideas. > > > > > > Lastly, I do not understand why it is perceived as the responsibility > of > > > the editor to do any study that other members of the group feel is > required. > > > That expectation will not scale. > > > > > > -- > > > "Mixed up signals > > > Bullet train > > > People snuffed out in the brutal rain" > > > --Conner Oberst > > > > > > > > > > > > > > -- > > 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 > > > > > > -- 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 From hsivonen at iki.fi Sat May 3 02:37:04 2008 From: hsivonen at iki.fi (Henri Sivonen) Date: Sat, 3 May 2008 12:37:04 +0300 Subject: [html4all] HTML5 Alternative Text, and Authoring Tools In-Reply-To: <481B283A.3040701@gmx.de> References: <006401c8abb8$b16a3940$da3142ab@stanford.edu> <55687cf80805011145n245a7b7cl28b67fa9c4905689@mail.gmail.com> <55687cf80805011310n22f3759en576b031c65d341e6@mail.gmail.com> <481A3D18.7000302@cam.ac.uk> <481B283A.3040701@gmx.de> Message-ID: On May 2, 2008, at 17:42 , Julian Reschke wrote: > In doubt, the default should be not to change HTML4. FWIW, I have a different view of what to do when in doubt: When in doubt, do what doesn't cause harm. I think experience (yes, not written down quantitatively) with HTML4 validation shows that casting an *accessibility* requirement into a simplistic presence/absence *syntax* requirement does both good (reminds some people to provide useful alt who somehow wouldn't otherwise) and harm (induces people to pollute non-graphical presentation with duplicate data, useless data like "image" or make the context less understandable by concealing the presence of images). I believe the current design in HTML 5 and Validator.nu's Image Report feature will pretty much remove the bad effects of requiring alt for validation. Thus, if we consider some kind of indifferent zero level of aggregate goodness/badness, it removes the negative side, so other things can only leave the aggregate positive or to the zero level. In all likelihood, it will also lop off *some* of the good effects. Still, it seems totally implausible that people who provide alt because they care about accessibility would suddenly stop if it weren't a machine-checkable *syntax* requirement. Hence, it seems plausible that the aggregate effect will remain on the positive side. Taking a course of action that has both good and bad effects on top of a net-positive aggregate baseline means seeking to do some good while accepting collateral damage of the bad side. I think a course of action with collateral damage should be based on data about the aggregate delta effect of the course of action remaining positive. We don't have data about that, so defaulting to removing the negative side without knowing the magnitude of either makes sense. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From rob at robburns.com Sat May 3 06:13:23 2008 From: rob at robburns.com (Robert J Burns) Date: Sat, 3 May 2008 13:13:23 +0000 Subject: [html4all] alt and authoring practices In-Reply-To: <481C183B.9010100@malform.no> References: <481C183B.9010100@malform.no> Message-ID: <57FDC09F-1D19-4C8A-9AA1-C11995CFCC3B@robburns.com> Looking over the lengthy discussions on the alt issue, it seems to me there's some fundamental misunderstandings going on: especially regarding the omission examples. Since alt is properly used as an alternative when the doc.ument is not available (leaving longdesc and other mechanisms for other textual content), then the often sited Flickr example doesn't really apply. I'm more familiar with iPhoto (and its integration with .mac), so let me use that as an example. iPhoto extracts sometimes hundreds of photos from my camera in a bulk operation. With a few clicks I can publish those photographs to the web as a web gallery. These photographs are presented as a web gallery along my other web galleries. A visitor to the web gallery sees the following: 1) the initial web gallery page with a 'key' photograph for each gallery (like a photo album). This key photo constitutes a navigable link to view the thumbnails of all of the photos in the gallery. It is a photo that should therefore have appropriate value for its alt attribute. Something along the lines of "view entire x gallery", where x is the name I've given to the gallery in iPhoto. 2) next on the gallery page, each photo in the gallery is represented by a thumbnail. By clicking on the thumbnail a higher resolution and larger photo is loaded. Again, these thumbnails require alt text. Something like "view fullsize image" or view image y fullsize" where y is the name of the photo. The initial name of the photo is automatically generated by iPhoto or my camera and usually in the form IMG_####.jpg. This means the alt attribute would look like this: ?alt='view image "IMG_1234" fullsize?. If I changed the name of the photo to be more title-like it might instead be: ? alt='view image "Joe at the Beech" fullsize' ?. 3) Finally the image is displayed full size with a series of controls for downloading and viewing the next image. Here the image "Joe at the Beech" would properly have the attribute ?alt='return to contact sheet of the entire gallery '?. Here the alt is easily generated by the software authoring tool. The controls on the page are iconic and therefore also require alt text: and again it is alt text automatically derived from the title of the photos (or simply "download photo", "next photo", and "previous photo" to avoid adding the titles of the relevant three photos). In this iPhoto scenario it is very rudimentary for iPhoto to add the appropriate alt text to every one of these photos. It doesn't matter that I'm adding hundreds or even thousands of photos to my html document with just a few clicks in a GUI authoring tool. The user of iPhoto need not know anything about HTML4, HTML5, or have ever heard of the W3C. Where things might matter is with the optional longdesc attribute, or with the image format supported description and title metadata. Here, iPhoto allows me to add descriptions to my photos and give them appropriate titles. However, that information remains in the image supported metadata (inside the jpeg file) and is not included as a document fragment with a longdesc attribute reference pointing to the document fragment. Here, it may be cumbersome for user (author) to provide descriptions of every photo of hundreds uploaded to the web. However, it is even more disappointing for an author who has already included such descriptions to have their authoring tool leave them out of the generated content. Again, this has nothing to do with the @alt attribute however. The @longdesc attribute is optional in HTML4 (and clearly some mechanism to explicitly associate embedded media with semantically rich descriptions should be included in HTML5) If Flikr has something different that I'm missing, then I think someone needs to elaborate how Flikr works that would necessitate some different approach and an optional alt. Take care, Rob From hsivonen at iki.fi Sat May 3 14:31:05 2008 From: hsivonen at iki.fi (Henri Sivonen) Date: Sun, 4 May 2008 00:31:05 +0300 Subject: [html4all] HTML5 Alternative Text, and Authoring Tools In-Reply-To: References: <006401c8abb8$b16a3940$da3142ab@stanford.edu> <55687cf80805011145n245a7b7cl28b67fa9c4905689@mail.gmail.com> <55687cf80805011310n22f3759en576b031c65d341e6@mail.gmail.com> <481A3D18.7000302@cam.ac.uk> <481B283A.3040701@gmx.de> Message-ID: On May 3, 2008, at 22:43 , Al Gilman wrote: > On 3 May 2008, at 5:37 AM, Henri Sivonen wrote: > >> On May 2, 2008, at 17:42 , Julian Reschke wrote: >> >>> In doubt, the default should be not to change HTML4. >> >> >> FWIW, I have a different view of what to do when in doubt: >> >> When in doubt, do what doesn't cause harm. >> >> I think experience (yes, not written down quantitatively) with >> HTML4 validation shows that casting an *accessibility* requirement >> into a simplistic presence/absence *syntax* requirement does both >> good (reminds some people to provide useful alt who somehow >> wouldn't otherwise) and harm (induces people to pollute non- >> graphical presentation with duplicate data, useless data like >> "image" or make the context less understandable by concealing the >> presence of images). > > Can you take the following re-statements as a 'yes'? > >> Syntactic presence of @alt on is not a sufficient technique >> for meeting >> WCAG 2.0 Success Criterion 1.1.1. > > >> Approximating the accessibility requirements for a text alternate >> with a syntactic >> requirement for @alt to be present can lead to erroneous practice. I think I agree with those statements. An aside on the topic of WCAG 2.0 (not a response to what you said): With WCAG 2.0 the W3C offers a notion of conformance on the accessibility evaluation axis. I'm curious why accessibility advocates want to bake some of that into the notion of conformance on the axis of machine-checkable HTML5 syntax instead of promoting conformance on the accessibility evaluation axis on its own right. So far, I've come up with two possible explanations: 1) It's about assuming that a notion of "Valid HTML5" is more appealing/marketable than a notion of "A[A][A] level conformance to WCAG 2.0". If this is it and such assumption were correct, wouldn't it mean that there'd be people who'd seek to satisfy a validator without necessarily doing good to accessibility in the process (and, therefore, we should be careful to avoid inducing that kind of behavior)? 2) The notion that a document could be deemed "correct" on *some* evaluation axis without *also* being accessible is somehow offensive. If this is it, I think it isn't productive to deny non-accessibility evaluation axes to use cases that aren't accessible to everyone, since there are legitimate use cases in the universe of possible Web pages that aren't accessible to everyone. For example, the Image Report feature of Validator.nu is by its very nature itself not accessible to a person who can't compare images and text. Is either of these on the mark or is there something else that I'm not realizing? >> I believe the current design in HTML 5 and Validator.nu's Image >> Report feature will pretty much remove the bad effects of requiring >> alt for validation. > > Two ideas: > > 1) Are you suggesting that HTML5 adopt some sort of a requirement or > other > endorsement of Validator.nu's Image Report feature? I'm not suggesting that. I am, however, suggesting that having the feature in the market-leading HTML5 validator should alleviate the concern that not making alt presence a machine-checkable *syntax* requirement somehow made the *accessibility* issue lose prominence. In fact, Validator.nu gives the alt issue more prominence than HTML 4 validators ever have. As a matter of *principle*, I think HTML 5 shouldn't *require* HTML5 validators to have particular additional features in addition to the HTML 5 validation function (i.e. deciding if the input meet machine- checkable syntax requirements), since the additional features beyond strict interoperability of the validation function should be an area where implementations are allowed to innovate and compete. As a practical matter, though, I wouldn't object to HTML 5 requiring or recommending HTML5 validators to have features that I've already implemented. Also, I wouldn't object to accessibility advocates objecting to any product or service that tried to compete with Validator.nu without having a similar feature. :-) > This is expressly > excluded from the job of a conformance checker in the current TR draft > of HTML5. > > http://www.w3.org/TR/html5/#conformance Indeed, in Validator.nu, the Image Report is not part of the HTML5 validation function. The outcome of the validation function is computable. The Image Report doesn't give a computed yay or nay. Instead, it presents information to help a human make assessments. > 2) It would seem to me that the value added by Validator.nu's Image > Report > feature is insensitive to whether @alt is required or not required. > It reduces the criticality of the question, but does not bias the > answer > one way or the other. I think it is sensitive to the issue. As a practical matter, at this point the market-leading HTML5 validator is addressing the *accessibility* issue, so the need to make it into a *syntax* issue is greatly reduced if not completely removed. Compared to making it into a syntax issue, the UI of the Image Report is carefully designed to avoid the downsides of making it a syntax issue: The Image Report always lists *all* elements of the input page. There is no way to make the list shorter (without removing images). This means that there's no bogus value that an author could include in order to make the report look shorter/cleaner. I don't want to even add warnings to the *syntax* check report, because it would reintroduce the problem of authors seeking to make the report look shorter by including bogus data. >> Thus, if we consider some kind of indifferent zero level of >> aggregate goodness/badness, it removes the negative side, so other >> things can only leave the aggregate positive or to the zero level. >> >> In all likelihood, it will also lop off *some* of the good effects. >> Still, it seems totally implausible that people who provide alt >> because they care about accessibility would suddenly stop if it >> weren't a machine-checkable *syntax* requirement. Hence, it seems >> plausible that the aggregate effect will remain on the positive side. > > You are leaving out the authors who don't care about accessibility > before > they are nagged, but yet do the right thing when nagged. > > Not everyone who discovers @alt via a conformance check stuffs > garbage in the > attribute. That's what I was referring to when I said "In all likelihood, it will also lop off *some* of the good effects." To mitigate the problem of lopping off some good effects, Validator.nu gives the alt issue more prominence than HTML 4 validators ever have: The HTML5 facet of Validator.nu gives one third of its UI input real estate to the image report feature (one out of three changeable input widgets) and the report about alt values is way more thorough than just flagging absence. >> Taking a course of action that has both good and bad effects on top >> of a net-positive aggregate baseline means seeking to do some good >> while accepting collateral damage of the bad side. I think a course >> of action with collateral damage should be based on data about the >> aggregate delta effect of the course of action remaining positive. >> >> We don't have data about that, so defaulting to removing the >> negative side without knowing the magnitude of either makes sense. > > Except that your argument that we are removing only negative is > debatable, > not prima_facie convincing. I am not putting forward an argument claiming to remove only the negative. ("In all likelihood, it will also lop off *some* of the good effects.") I am putting forward an argument that the net effect will be on the positive side even if we don't seek to gain some unknown magnitude of incremental positiveness in a way that is known to incur an unknown magnitude of collateral negativeness. > What seems to be broadly agreeable is that Validator.nu's Image > Report adds significant > value to the authoring process. But the HTML5 draft currently > disowns this value. I think the practical value isn't removed even if HTML 5 "disowns" it, but I'd be OK with the spec acknowledging it. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From foliot at wats.ca Thu May 8 09:58:32 2008 From: foliot at wats.ca (John Foliot) Date: Thu, 8 May 2008 09:58:32 -0700 Subject: [html4all] HTML Action Item 54 - ...draft text for HTML 5 spec to require producers/authors to include @alt on img elements. In-Reply-To: <55687cf80805080828y1ae4304bn326999393d22288e@mail.gmail.com> Message-ID: <007901c8b12c$bfd1e360$723d42ab@stanford.edu> Steven Faulkner wrote: > Dear HTML WG members, > > The first draft of our rewrite of major sections of 3.12.2 "The img > element" in the HTML5 draft is now available: Bravo to all involved - well done! Now we await their response... JF From laura.lee.carlson at gmail.com Fri May 9 02:06:32 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Fri, 9 May 2008 04:06:32 -0500 Subject: [html4all] Discussion Action 54: First draft of the rewrite of "The img element" Message-ID: <1c8dbcaa0805090206y49e7279fyb4898ee61f85ef35@mail.gmail.com> Hello Everyone, As Steve Faulkner reported [1] yesterday he, Joshue O Connor, and I have completed the first draft [2] of action 54 to rewrite major sections of 3.12.2 "The img element". The document has been peer reviewed by Gez Lemon and Gregory Rosmaita. We would love to have your input. Please send your comments to this thread by May 22. A copy of the draft is also in the Wiki [3]. Your feedback will be instrumental in moving forward on this issue. Thank you. Best Regards, Laura [1] http://lists.w3.org/Archives/Public/public-html/2008May/0121.html [2] http://www.paciellogroup.com/blog/misc/uc/ [3] http://esw.w3.org/topic/HTML/Action54AltAttribute Best Regards, Laura -- Laura L. Carlson From laura.lee.carlson at gmail.com Fri May 9 17:58:21 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Fri, 9 May 2008 19:58:21 -0500 Subject: [html4all] Discussion Action 54: First draft of the rewrite of "The img element" In-Reply-To: <37699E3B17FF4B928BF678918164AD8F@HANDS> References: <1c8dbcaa0805090206y49e7279fyb4898ee61f85ef35@mail.gmail.com> <37699E3B17FF4B928BF678918164AD8F@HANDS> Message-ID: <1c8dbcaa0805091758j33851d91y8f632223a0c79102@mail.gmail.com> If anyone is using JAWS 8 and 9 with Windows XPSP3 and IE6, and is having trouble accessing the Action 54 document [1], please use the Wiki copy [2]. It has been reported that particular configuration may be tripped up by abbr and title. Many thanks to David Poehlman for reporting this. Everyone's comments are vital for us to improve the draft. Best Regards, Laura [1] http://www.paciellogroup.com/blog/misc/uc/ [2] http://esw.w3.org/topic/HTML/Action54AltAttribute -- Laura Carlson From laura.lee.carlson at gmail.com Sat May 10 04:09:59 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Sat, 10 May 2008 06:09:59 -0500 Subject: [html4all] Discussion Action 54: First draft of the rewrite of "The img element" In-Reply-To: <1c8dbcaa0805090206y49e7279fyb4898ee61f85ef35@mail.gmail.com> References: <1c8dbcaa0805090206y49e7279fyb4898ee61f85ef35@mail.gmail.com> Message-ID: <1c8dbcaa0805100409n26aa12f4q822fc480df264111@mail.gmail.com> Hi Katie, Thank you for your cogent and constructive comments. You set a fine example of how to comment on the document. You stated: - The specific text that you are addressing - Proposed verbiage for the change you would like made - The reasoning behind your change This is excellent. It is exactly the type of feedback that we will need to improve the document. Much appreciated. Best Regards, Laura -- Laura Carlson On 5/9/08, Katie Haritos-Shea wrote: > Laura, > > First I would like to note that I am not a member of the HTML 5 working > group, but I have been a member of WCAG 2.0 for many years. > > Having said that, I do have a two quick comments regarding the Action 54: > First Draft at > [3] http://esw.w3.org/topic/HTML/Action54AltAttribute. > > > Comment 1: > Suggest changing "General alt Text Good Practices" to "General alt Text - > Best Practices". > > > Comment 2: > > For...... > Images of Text > Description > Images of text are pictures of alphabetic or numeric textual characters. > > Suggestion, for i18n purposes should this description not include the > concept of *pictures of* 'ASCII Art', which is a pattern of characters or > character glyphs whereby, I think, a single glyph can represent a word, > thought or phrase (this is a specific representation that is not equal to a > symbol)? > > Suggest changing "Images of text are pictures of alphabetic or numeric > textual characters." to > "Images of text are pictures of alphabetic, glyph or numeric textual > characters." > > > (A longer version could be "Images of text are pictures of alphabetic or > numeric textual characters, and ASCII Art that represent a word, thought or > phrase.", but would be redudnant considering the 'Examples include pictures > of:' list that follow the description) > > > > (BTW - your team has done a good job with this draft) > > > Katie > > > > > -----Original Message----- >>From: Laura Carlson >>Sent: May 9, 2008 5:06 AM >>To: "public-html at w3.org" >>Cc: Dan Connolly , Chris Wilson >> , "Michael(tm) Smith" , W3C >> WAI-XTECH , wai-liaison at w3.org, html4all >> >>Subject: Discussion Action 54: First draft of the rewrite of "The img >> element" >> >> >>Hello Everyone, >> >>As Steve Faulkner reported [1] yesterday he, Joshue O Connor, and I >>have completed the first draft [2] of action 54 to rewrite major >>sections of 3.12.2 "The img element". The document has been peer >>reviewed by Gez Lemon and Gregory Rosmaita. >> >>We would love to have your input. Please send your comments to this >>thread by May 22. A copy of the draft is also in the Wiki [3]. >> >>Your feedback will be instrumental in moving forward on this issue. >> >>Thank you. >> >>Best Regards, >>Laura >> >>[1] http://lists.w3.org/Archives/Public/public-html/2008May/0121.html >>[2] http://www.paciellogroup.com/blog/misc/uc/ >>[3] http://esw.w3.org/topic/HTML/Action54AltAttribute >> >>Best Regards, >>Laura >>-- >>Laura L. Carlson >> > > > * katie * > > Katie Haritos-Shea > Section 508 Technical Policy Analyst > > 703-371-5545 > > People may forget exactly what it was that you said or did, > but they will never forget how you made them feel....... From rob at robburns.com Sat May 10 05:45:17 2008 From: rob at robburns.com (Robert J Burns) Date: Sat, 10 May 2008 12:45:17 +0000 Subject: [html4all] alt Flickr and iPhoto/dot Mac Message-ID: Hello 4all, I'm interested in the hearing the views of this group on the topic I recently raised of the age-old Flickr example. I switched it from Flickr to iPhoto/dot Mac because that is what I am familiar with, and Smylers acknowledged on the WG list that it is substantially the same example. The thread starts here[1], but my point was essentially that the Flickr example doesn't hold water. In light of the newly drafted IMG section I wonder if the drafters and others could comment on this concrete example. Essentially I argue that the iPhoto/ dot Mac authoring faces no such dilemma, as so often argued. Instead, the implementors of the iPhoto/dot Mac authoring tool have all the information they require to produce a conforming and accessible web page using the titles either generated by the application or titles further improved and made more human readable by the authors themselves. Either way it should be simple to produce an HTML5 web document ? and web application in this case ? that is accessible, conforming and automating the bulk upload of photos. So my curiosity relates to two things: 1) if we apply the tenets of the newly re-drafted image element and the related alt best practices to this iPhoto/dot Mac example does it overcome the often cited Flickr objections. 2) I'd like to hear from assistive technology users what the current situation is in using this photo gallery[2]. My sense is that Apple has gone way too far with javascript and ? aside from the other frustrations and degraded user experience that creates ? I'm concerned that it may also be thoroughly inaccessible (leaving aside the issue of human-unfriendly image titles like IMG_1234.JPG). So if others could check how JAWS and VoiceOver, etc. does with this site, I'd be interested in hearing the results. Just to clarify the titles of the images could be improved (by me in a manual and potentially cumbersome process). However, my interest is in assessing the overall accessibility of the application/ documents when relying only on the bulk processing of the photos. My sense is that this example shows that requiring appropriate alt values places no insurmountable burden on the implementors of such bulk automated authoring tools nor necessarily on the authors using those tools (where I'm free to add meaningful titles to as many of the photos as I'd like with each one improving the accessibility and overall usability of my photo galleries). Take care, Rob [1]: with a few replies in May [2]: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080510/dcffab9d/attachment.html From rob at robburns.com Sat May 10 07:33:33 2008 From: rob at robburns.com (Robert J Burns) Date: Sat, 10 May 2008 14:33:33 +0000 Subject: [html4all] alt Flickr and iPhoto/dot Mac In-Reply-To: References: Message-ID: <780CD688-7DDD-48D9-8C51-0D0C9F20E666@robburns.com> On this issue of iPhoto/dot Mac, I think one place I can see for improvement is in dropping the filename extension from the title of the photo. In other words, iPhoto automatically provides the filenames of IMG_###.JPG and also includes that same filename in the title of the photo in the files metadata. Unfortunately iPhoto also moves the filename extension (.jpg) to the photographs title property, which I think is unnecessary and unwanted. In this way the title of each photo (or the alt value if the titles as captions are omitted from the document) would become less cumbersome to listen to. Obviously as I change the titles to more human readable titles I'm not going to maintain the .jpg in the title, so why should iPhoto automatically transfer that filename extension to the title property. iPhoto also allows me to provide long descriptions of the photo, but there is no way to have iPhoto move those long descriptions to the web gallery appropriately referenced with a longdesc attribute. Take care, Rob On May 10, 2008, at 12:45 PM, Robert J Burns wrote: > Hello 4all, > > I'm interested in the hearing the views of this group on the topic I > recently raised of the age-old Flickr example. I switched it from > Flickr to iPhoto/dot Mac because that is what I am familiar with, > and Smylers acknowledged on the WG list that it is substantially the > same example. > > The thread starts here[1], but my point was essentially that the > Flickr example doesn't hold water. In light of the newly drafted IMG > section I wonder if the drafters and others could comment on this > concrete example. Essentially I argue that the iPhoto/ dot Mac > authoring faces no such dilemma, as so often argued. Instead, the > implementors of the iPhoto/dot Mac authoring tool have all the > information they require to produce a conforming and accessible web > page using the titles either generated by the application or titles > further improved and made more human readable by the authors > themselves. Either way it should be simple to produce an HTML5 web > document ? and web application in this case ? that is accessible, > conforming and automating the bulk upload of photos. > > So my curiosity relates to two things: > > 1) if we apply the tenets of the newly re-drafted image element and > the related alt best practices to this iPhoto/dot Mac example does > it overcome the often cited Flickr objections. > 2) I'd like to hear from assistive technology users what the current > situation is in using this photo gallery[2]. My sense is that Apple > has gone way too far with javascript and ? aside from the other > frustrations and degraded user experience that creates ? I'm > concerned that it may also be thoroughly inaccessible (leaving aside > the issue of human-unfriendly image titles like IMG_1234.JPG). So if > others could check how JAWS and VoiceOver, etc. does with this site, > I'd be interested in hearing the results. > > Just to clarify the titles of the images could be improved (by me in > a manual and potentially cumbersome process). However, my > interest is in assessing the overall accessibility of the > application/documents when relying only on the bulk processing of > the photos. My sense is that this example shows that requiring > appropriate alt values places no insurmountable burden on the > implementors of such bulk automated authoring tools nor necessarily > on the authors using those tools (where I'm free to add meaningful > titles to as many of the photos as I'd like with each one improving > the accessibility and overall usability of my photo galleries). > > Take care, > Rob > > > [1]: > with a few replies in May > > > [2]: > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wilbur.bytowninternet.com/pipermail/list_html4all.org/attachments/20080510/a1e2a638/attachment.html From oedipus at hicom.net Sun May 11 11:23:45 2008 From: oedipus at hicom.net (Gregory J. Rosmaita) Date: Sun, 11 May 2008 19:23:45 +0100 Subject: [html4all] [Resource Limitation] lack of discussion pages on ESW wiki Message-ID: <20080511181119.M91838@hicom.net> aloha! the review of materials on the ESW wiki in HTML topic space is severely hampered by the lack of "discussion" pages for each wiki page -- without which, the only way to engage in "discussion" via the wiki is to directly edit a wiki page, which can completely distort the original intention of the page; a simple example is the wiki page located at: http://esw.w3.org/topic/HTML/Action54AltAttribute which reflects a proposal submitted to the working group; discussion of this proposal on the ESW wiki SHOULD be facilitated through an associated discussion page, so that comments upon the content of a particular wiki article can be addressed without either materially changing the content of a wiki article or causing article bloat as more careful commentators append their proposals to a wiki article at the end of the original article, which often means repeating a lot of text... is this something which can be corrected in a timely manner? is it even possible with MoinMoin? gregory. -------------------------------------------------------------- DISCUSSION, n. A method of confirming others in their errors. -- Ambrose Bierce, The Devil's Dictionary -------------------------------------------------------------- Gregory J. Rosmaita, oedipus at hicom.net Camera Obscura: http://www.hicom.net/~oedipus/ -------------------------------------------------------------- From oedipus at hicom.net Sun May 11 11:44:51 2008 From: oedipus at hicom.net (Gregory J. Rosmaita) Date: Sun, 11 May 2008 19:44:51 +0100 Subject: [html4all] alt Flickr and iPhoto/dot Mac In-Reply-To: References: Message-ID: <20080511183853.M22446@hicom.net> aloha, rob! here are 2 less-than-fully cogent thoughts from my original comments on action 54 -- if you convert them from gregorian to burnsian, i'm sure that my points will make a hell of a lot more sense : 1. a meta-comment on providing alt and a long descriptor (best practice) for ultimate fallback purposes, it should be suggested that the descriptor text be included in the code which contains the image -- just as the server side software at my.opera.com is able to pull out all of the meta-data stamped on the photographs taken by a friend (such as, camera make, shutter speed, etc. http://my.opera.com/oedipus/albums/show.dml?id=347539) -- when someone uses clip art (or, when an authoring tool provides clip art), the descriptors should already be part of the image file, no matter what its format -- just as one can modify, change and/or reorder the meta- information on a MP3 file, so should authoring tools encourage authors to (or enable authors to), when they fill in the ALT, LEGEND and LongDescriptor fields when adding an image; optimally, the authoring tool would pre-populate the fields with the meta-information contained in the image, and then modify it in accordance with what the author decides to put in the ALT, LEGEND and LongDescriptor fields); 2. for graphical representations of mathematics, the best practice (which needs to migrate to WCAG2) is to include in the image the mathematical expression in either TeX and/or MathML, so that it is available to a MathML renderer or a TeX to MathML converter (consult: http://www.dessci.com) -- this overcomes the problem of "no rich text or markup in ALT", as ALT defined in ASCII for mathematical equations tends to be EXTREMELY poor and/or insufficient; oh, and if you haven't checked out matt may's "alt the flickr defense", it makes for some interesting reading: http://www.bestkungfu.com/archive/date/2008/05/alt-and-the-flickr-defense more soon, gregory. ------------------------------------------------------------ The more things are forbidden, the more popular they become. -- Mark Twain ------------------------------------------------------------ Gregory J. Rosmaita: oedipus at hicom.net Camera Obscura: http://www.hicom.net/~oedipus/ Oedipus' Online Complex: http://my.opera.com/oedipus ------------------------------------------------------------ From laura.lee.carlson at gmail.com Sun May 11 13:15:35 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Sun, 11 May 2008 15:15:35 -0500 Subject: [html4all] Action 54: First Draft. (was Re: [Resource Limitation] lack of discussion pages on ESW wiki) Message-ID: <1c8dbcaa0805111315i2e9cd66cw6d0c558a2c290207@mail.gmail.com> Hi Gregory, > the review of materials on the ESW wiki in HTML topic space is > severely hampered by the lack of "discussion" pages for each > wiki page -- without which, the only way to engage in "discussion" > via the wiki is to directly edit a wiki page, which can completely > distort the original intention of the page; a simple example is the > wiki page located at: > > http://esw.w3.org/topic/HTML/Action54AltAttribute It would be wonderful to have discussion pages in the ESW Wiki ala MediaWiki. But in the mean time, I set up a separate Wiki "discussion" page for Action 54: First Draft. It is at: http://esw.w3.org/topic/HTML/Action54AltAttributeDiscussion Best Regards, Laura -- Laura L. Carlson From rob at robburns.com Mon May 12 02:22:23 2008 From: rob at robburns.com (Robert J Burns) Date: Mon, 12 May 2008 09:22:23 +0000 Subject: [html4all] alt Flickr and iPhoto/dot Mac In-Reply-To: <20080511183853.M22446@hicom.net> References: <20080511183853.M22446@hicom.net> Message-ID: <84907A73-7C19-4E23-B0C5-4374667E8D90@robburns.com> Hi Gregory, On May 11, 2008, at 6:44 PM, Gregory J. Rosmaita wrote: > oh, and if you haven't checked out matt may's "alt the flickr > defense", > it makes for some interesting reading:[1] Thanks for the link to Matt May?s article. It was informative. However, my point goes beyond what Matt is saying there. My point is that if one actually considers best practices for alt in designing a site like Flickr or iPhoto/dot Mac authoring, one will quickly discover that this age-old Flickr example is based on a fundamental misunderstanding of how the alt attribute is used. Using this iPhoto /dot Mac, I showed how the software authoring tools involved never need to prompt the user for the alt text. All of the necessary alt text can be provided by the authoring tool itself with no author input whatsoever. I think this is true especially in light of the great work Steve, Laura, and Josh did on the new re-draft of the image section (in action item 54). That is not to say that authors cannot make the resulting site more accessible and more usable generally. Spending more time providing author generated titles, author generated descriptions and other metadata will indeed make the site more accessible and more usable[2]. However, the claim that an authoring tool cannot do the job of being both accessible and conforming ? if alt is required ? is completely false (and mistaken for not actually considering a concrete example such as iPhoto / dot Mac). In fact, nothing the author does changes how the authoring tool should generate alt text in this example (iPhoto could improve things too by not including the filename extension in the image files title property, but only the automatically generated filename without the extension; there's no reason to include a filename extension in a photograph title). BTW Gregory, I do agree that authoring tools should extract the image file's description metadata to a document fragment referenced by the longdesc attribute. I also think HTML5 should be encouraging client UAs to do the same thing. Again, iPhoto / dot Mac provide an example of the need for this use case. Users visiting my galleries can click on an information button when viewing a photo to view some of the metadata (the machine generated metadata only, such as the shutter speed, f-stop ,etc). I think browsers especially should be capable of extracting the titles, captions and descriptions from the image file itself and provide it to a user upon request. Perhaps we should even propose new metadata properties for image formats that permit HTML fragments within an image file to enable semantically rich subject descriptions and visual descriptions. Take care, Rob [1]: http://www.bestkungfu.com/archive/date/2008/05/alt-and-the-flickr-defense [2]: After all the main thrust for Apple with iPhoto is how easy it makes it for authors to prepare their photos for sharing with others. The main focus for Apple is on such things as cropping, rotating, adjusting color, adjusting brightness, etc..I think their missing much regarding how users also want to improve the metadata about their photos. However, recently they did make 'event' metadata central with iPhoto ensuring that every photo in an authors library has an event assigned to it. Unfortunately Apple maintains this metadata outside the image file rather than utilizing industry standard metadata property for 'event'. Similarly Apple does not include the description in the image file and is inconsistent in how it stores other descriptive metadata (often not using obvious IPTC properties for storing metadata). From joshue.oconnor at cfit.ie Mon May 12 04:54:25 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Mon, 12 May 2008 12:54:25 +0100 Subject: [html4all] alt Flickr and iPhoto/dot Mac In-Reply-To: <84907A73-7C19-4E23-B0C5-4374667E8D90@robburns.com> References: <20080511183853.M22446@hicom.net> <84907A73-7C19-4E23-B0C5-4374667E8D90@robburns.com> Message-ID: <48282FF1.2010501@cfit.ie> HI Robert, Thanks for the heads up with this (and the kind words) > Using this iPhoto /dot Mac, I showed how the software authoring tools > involved never need to prompt the user for the alt text. All of the > necessary alt text can be provided by the authoring tool itself with > no author input whatsoever. I think this is true especially in light > of the great work Steve, Laura, and Josh did on the new re-draft of > the image section (in action item 54). It makes sense to me to make it very easy for the software authoring tools to make the provision of descriptive metadata as simple as possible. I also like the idea of a tool being able to intelligently choose what information it allows into the layer, from assessing the /ingredients/ (author provided descriptions/ file names etc) to deciding how how to present them. You are right that taking the file extension and using that as a human readable descriptor is useless. Clever mechanisms/heuristics that will allow the creation of more accessible content by associating images with author generated text/descriptions, /without/ the author even be aware that they are including @alt or a @longdesc, @future_att etc, also sounds like a good idea. You also make a good point about the design of the tool itself and how important its role is. This is a part of the problem with the Flicker defense etc. This is only one tool, and also it could be viewed as a beta version as it is is relatively new. The tools in 10 years plus will be far more sophisticated (we hope) and by a combination of good design and a constraints based approach to how UAs /allow/ users to upload content and describe it, will improve the descriptive information that is available and therefore the quality of the accessible content. A back door to this by mainstreaming may do it. Don't say this is /only/ accessibility information you are adding, but that it can be used as a way of cross referencing other related libraries so the more meta descriptors there are the better, give you better ratings in the interesting galleries section or whatever. Cheers Josh From jason at jasonjgw.net Mon May 12 18:13:27 2008 From: jason at jasonjgw.net (Jason White) Date: Tue, 13 May 2008 11:13:27 +1000 Subject: [html4all] Discussion Action 54: First draft of the rewrite of "The img element" In-Reply-To: <1c8dbcaa0805090206y49e7279fyb4898ee61f85ef35@mail.gmail.com> References: <1c8dbcaa0805090206y49e7279fyb4898ee61f85ef35@mail.gmail.com> Message-ID: <20080513011327.GA6100@jdc.jasonjgw.net> On Fri, May 09, 2008 at 04:06:32AM -0500, Laura Carlson wrote: > We would love to have your input. Please send your comments to this > thread by May 22. A copy of the draft is also in the Wiki [3]. This proposal is much more consistent with W3C accessibility guidelines, developed over many years, than the text currently in the HTML 5 draft. As a result, it is more in line with best practice and policy in organizations that have adopted the Web Content Accessibility Guidelines, and which, in the time-frame for the development of HTML 5, will move toward the implementation of WCAG 2.0, which is now a W3C Candidate Recommendation. It should also be noted that these guidelines have been incorporated into policy, directly or indirectly, in a number of jurisdictions, and that future versions of HTML should be consistent with W3C accessibility guidelines as well as the practices that have emerged in support of them. My reservations regarding this proposal are as follows. It provides much non-normative guidance in the application of the ALT attribute, which may not be appropriate for inclusion in a markup language specification, and which moreover could be seen as usurping the role of WCAG 2.0 and its techniques documents. A format specification is not a tutorial. Nevertheless, there is a legitimate role for non-normative explanations in clarifying the normative content. I think the discussion in this case should be confined to a concise description, consistent with WCAG 2.0, of the function of @alt, a brief discussion of the various possibilities as outlined in WCAG 2, guideline 1.1, and a reference to that specification and its techniques for further details. Much attention has been paid to the syntactic question of whether @alt should be a required attribute. Ultimately, this depends on the question of what validating implementations of HTML 5 should treat as correct - what kinds of errors should be flagged by validators, whether operating as stand-alone applications or in authoring tools. Given the HTML 5 approach to error handling in user agents, it seems that regardless of how the syntactic issue surrounding @alt is decided, the specification will need to define graceful error handling behaviour, to be consistently implemented by user agents, in the case of a missing @alt. The present proposal does not address this issue. I think it would be helpful if the working group were to clarify, as a preliminary to addressing the syntactic issue of whether @alt should be mandatory, the role of validating implementations and the extent to which validity requirements should be designed to encourage, and to identify possible departures from, good authoring practices, including practices required by other W3C specifications such as WCAG 2.0. I would also suggest that consideration be given to the possibility of multiple levels of validation, of distinguishing, for example, fatal errors from warnings, as compilers do in parsing source code. It should also be borne in mind that accessibility-related validators play an important role in assuring conformance to those aspects of WCAG 2.0 that are testable at a syntactic level, and in notifying authors of potentially non-conforming content. Perhaps there needs to be a broader specification covering HTML validation that would encompass internationalization, accessibility and other authorial best practices, identifying aspects which can be tested by syntax alone and the kinds of warnings or errors that should be given in each case. These requirements would also apply to code generators and other authoring tools which impose syntactic constraints beyond those required for HTML parsing, on the document instances that they produce. From faulkner.steve at gmail.com Tue May 13 00:53:21 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Tue, 13 May 2008 08:53:21 +0100 Subject: [html4all] Discussion Action 54: First draft of the rewrite of "The img element" In-Reply-To: <20080513011327.GA6100@jdc.jasonjgw.net> References: <1c8dbcaa0805090206y49e7279fyb4898ee61f85ef35@mail.gmail.com> <20080513011327.GA6100@jdc.jasonjgw.net> Message-ID: <55687cf80805130053x6dba9b8dw7e82a89142dbeac9@mail.gmail.com> Hi Jason, thanks for your well considered and insightful comments. I look forward to reading interested parties thoughts on your comments. best regards stevef On 13/05/2008, Jason White wrote: > On Fri, May 09, 2008 at 04:06:32AM -0500, Laura Carlson wrote: > > > We would love to have your input. Please send your comments to this > > thread by May 22. A copy of the draft is also in the Wiki [3]. > > This proposal is much more consistent with W3C accessibility guidelines, > developed over many years, than the text currently in the HTML 5 draft. As a > result, it is more in line with best practice and policy in organizations that > have adopted the Web Content Accessibility Guidelines, and which, in the > time-frame for the development of HTML 5, will move toward the implementation > of WCAG 2.0, which is now a W3C Candidate Recommendation. It should also be > noted that these guidelines have been incorporated into policy, directly or > indirectly, in a number of jurisdictions, and that future versions of HTML > should be consistent with W3C accessibility guidelines as well as the > practices that have emerged in support of them. > > My reservations regarding this proposal are as follows. > > It provides much non-normative guidance in the application of the ALT > attribute, which may not be appropriate for inclusion in a markup language > specification, and which moreover could be seen as usurping the role of WCAG > 2.0 and its techniques documents. A format specification is not a tutorial. > Nevertheless, there is a legitimate role for non-normative explanations in > clarifying the normative content. I think the discussion in this case should > be confined to a concise description, consistent with WCAG 2.0, of the > function of @alt, a brief discussion of the various possibilities as outlined > in WCAG 2, guideline 1.1, and a reference to that specification and its > techniques for further details. > > Much attention has been paid to the syntactic question of whether @alt should > be a required attribute. Ultimately, this depends on the question of what > validating implementations of HTML 5 should treat as correct - what kinds of > errors should be flagged by validators, whether operating as stand-alone > applications or in authoring tools. Given the HTML 5 approach to error > handling in user agents, it seems that regardless of how the syntactic issue > surrounding @alt is decided, the specification will need to define graceful > error handling behaviour, to be consistently implemented by user agents, in > the case of a missing @alt. The present proposal does not address this > issue. > > I think it would be helpful if the working group were to clarify, as a > preliminary to addressing the syntactic issue of whether @alt should be > mandatory, the role of validating implementations and the extent to which > validity requirements should be designed to encourage, and to identify > possible departures from, good authoring practices, including practices > required by other W3C specifications such as WCAG 2.0. I would also suggest > that consideration be given to the possibility of multiple levels of > validation, of distinguishing, for example, fatal errors from warnings, as > compilers do in parsing source code. It should also be borne in mind that > accessibility-related validators play an important role in assuring > conformance to those aspects of WCAG 2.0 that are testable at a syntactic > level, and in notifying authors of potentially non-conforming content. Perhaps > there needs to be a broader specification covering HTML validation that would > encompass internationalization, accessibility and other authorial best > practices, identifying aspects which can be tested by syntax alone and the > kinds of warnings or errors that should be given in each case. These > requirements would also apply to code generators and other authoring tools > which impose syntactic constraints beyond those required for HTML parsing, on > the document instances that they produce. > > > _______________________________________________ > 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 From laura.lee.carlson at gmail.com Tue May 13 05:15:08 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Tue, 13 May 2008 07:15:08 -0500 Subject: [html4all] Discussion Action 54: First draft of the rewrite of "The img element" In-Reply-To: <20080513011327.GA6100@jdc.jasonjgw.net> References: <1c8dbcaa0805090206y49e7279fyb4898ee61f85ef35@mail.gmail.com> <20080513011327.GA6100@jdc.jasonjgw.net> Message-ID: <1c8dbcaa0805130515j488393d8jef95993c6d2479c@mail.gmail.com> Hi Jason, Perfect, Jason, just the type of constructive criticism what we need. Thank you very much for thinking outside of the box and your mindful analysis. You pinpointed many areas for deliberation. Much appreciated. Best Regards, Laura -- Laura L. Carlson From rob at robburns.com Tue May 20 15:53:36 2008 From: rob at robburns.com (Robert J Burns) Date: Tue, 20 May 2008 22:53:36 +0000 Subject: [html4all] Issues for the Issue-tracker Message-ID: Hello Gregory and 4all, I'm starting to make some progress on the issue tracker items I spoke about earlier. My list has grown to about 30 some items. Many of these I feel should get into the draft sooner rather than later so that we can start to get feedback from implementations in the same way implementations are already anxiously adding preliminary experimental support for the video element for example. Also since some of these issues involve the introduction of new elements (something I would try to avoid for greater compatibility with legacy browsers), the earlier they appear in the draft of the HTML5 recommendation, the greater potential legacy support they may have[1][2]. After all, unlike the video element, UAs merely need to add these to the appropriate list in their parsing implementations to ensure something like the 'subtext' element (if that's what it gets called in the draft)[3] is parsed into the DOM in the same way as a element (thus requiring only author stylesheet for graceful legacy degradation). So I want to send each issue to Gregory and to the HTMl4All list as a separate email so that it can be discussed here as Gregory adds it to the issue-tracker and hopefully get discussed and advocated for at the teleconferences that I will no doubt be unable to attend. Many of these issues deal directly with accessibility, but some deal indirectly with accessibility and instead deal more directly with general authoring, semantics, and other issues we've discussed previously. Nevertheless, I hope to find support for them within this group. Laura had previously suggested attaching action items to these issues to ensure they get proper consideration. As I said earlier, I do not think I can attend the teleconferences, but I would be happy to accept assignments to draft corresponding language for the HTML recommendation for any of these newly raised issues. A few Issues to follow ? each in their own message ? with more in the pipeline. Take care, Rob [1]: [2]: [3]: From rob at robburns.com Tue May 20 15:55:24 2008 From: rob at robburns.com (Robert J Burns) Date: Tue, 20 May 2008 22:55:24 +0000 Subject: [html4all] Cross-referencing and subtext Message-ID: Cross-referencing and subtext. To provide semantic features in HTML5 supporting proposed styling features in CSS3 and because authors have an independent need to markup notes and cross references regardless of presentation. From rob at robburns.com Tue May 20 15:57:46 2008 From: rob at robburns.com (Robert J Burns) Date: Tue, 20 May 2008 22:57:46 +0000 Subject: [html4all] Definitions and Abbreviations cross-referencing Message-ID: <2BC4EBFB-618A-4CFF-951E-53358F8B53AD@robburns.com> Definitions and Abbreviations cross-referencing From rob at robburns.com Tue May 20 15:59:38 2008 From: rob at robburns.com (Robert J Burns) Date: Tue, 20 May 2008 22:59:38 +0000 Subject: [html4all] Support for eliminating authoring distinctions between block and non-block semantics Message-ID: Support for eliminating authoring distinctions between block and non- block semantics (particularly within the HTML5 DOM and XML serialization, but perhaps also in text/html serialization)[5] Proposal would allow authors to use only Q element and not need to worry about Q and BLOCKQUOTE distinctions (also could apply to CODE and BLOCKCODE if HTML5 adopted these semantics). From rob at robburns.com Tue May 20 16:00:47 2008 From: rob at robburns.com (Robert J Burns) Date: Tue, 20 May 2008 23:00:47 +0000 Subject: [html4all] Requirement to designate role for embedded content Message-ID: Requirement to designate role for embedded content. To ease the burden on authoring tools and authors, and to provide further information for UAs and users unable to consume non-text media provide an attribute and HTML specified attribute NCNames for designating the role of non- text media. From rob at robburns.com Tue May 20 16:01:46 2008 From: rob at robburns.com (Robert J Burns) Date: Tue, 20 May 2008 23:01:46 +0000 Subject: [html4all] For Q (quotation) and BLOCKQUOTE a 'marks' content markup attribute Message-ID: <05746A0B-986F-4E98-8203-D5859B191D26@robburns.com> For Q (quotation) and BLOCKQUOTE a 'marks' content markup attribute. Permits authors greater control over the separation of concerns of styling quotations and specifying the semantics of quotations within a document. Also allows authors to work around the current state of interoperability across popular UAs. From rob at robburns.com Tue May 20 16:14:13 2008 From: rob at robburns.com (Robert J Burns) Date: Tue, 20 May 2008 23:14:13 +0000 Subject: [html4all] Definitions and Abbreviations cross-referencing Message-ID: <703C1D7D-17A0-461C-9A64-952A9FE0D2B4@robburns.com> Definitions and Abbreviations cross-referencing. Provide a more complete and compact markup syntax for associating definitions, terms, variables, proper names and abbreviated forms. Also promote greater user enhancements within UA implementations for such semantics by automatically generating document subject and name indexes, glossaries and interactive UI for these semantics. From rob at robburns.com Tue May 20 16:36:30 2008 From: rob at robburns.com (Robert J Burns) Date: Tue, 20 May 2008 23:36:30 +0000 Subject: [html4all] Enhanced client-side Image Maps Message-ID: <24A25ED5-D7F6-49FA-B607-2287E8902DFB@robburns.com> Enhanced client-side Image Maps. Provide more complete specification of client-side image maps to improve accessibility and general usability and also entirely eliminate the need for server-side image map processing. From rob at robburns.com Tue May 20 17:00:32 2008 From: rob at robburns.com (Robert J Burns) Date: Wed, 21 May 2008 00:00:32 +0000 Subject: [html4all] Requirement to designate role for embedded content Message-ID: Markup support for bookmark and clipping support of documents. Provides a way to markup specific points within a document or contiguous sections of a document that may not be hierarchically well- formed (such as the pages of an archival document that may contain portions of a paragraph). From rob at robburns.com Tue May 20 17:06:18 2008 From: rob at robburns.com (Robert J Burns) Date: Wed, 21 May 2008 00:06:18 +0000 Subject: [html4all] Markup support for bookmark and clipping support of documents [incorrect subject on previous email] Message-ID: Markup support for bookmark and clipping support of documents. Provides a way to markup specific points within a document or contiguous sections of a document that may not be hierarchically well- formed (such as the pages of an archival document that may contain portions of a paragraph). From rob at robburns.com Tue May 20 17:25:43 2008 From: rob at robburns.com (Robert J Burns) Date: Wed, 21 May 2008 00:25:43 +0000 Subject: [html4all] Pronunciation attributes for abbreviations, variables, proper nouns and terms Message-ID: <57485DC0-FCAD-4B07-9A0C-24B067119B55@robburns.com> Pronunciation attributes for abbreviations, variables, proper nouns and terms. Adds phonetic and related pronunciation attributes for DFN, ABBR, VAR and proper names. Adds a phonetic attribute to several elements as well as type and expressedas attributes to the ABBR element. See also ? ? From rob at robburns.com Tue May 20 18:32:13 2008 From: rob at robburns.com (Robert J Burns) Date: Wed, 21 May 2008 01:32:13 +0000 Subject: [html4all] Markup improvements and UA norms to associate attributions, citations, quotations and references Message-ID: <89130E0B-77EF-48D9-8084-F3085171DFAD@robburns.com> Markup improvements and UA norms to associate attributions, citations, quotations and references. Adds some attributes for pages, annotations and ordered and unordered reference lists and UA norms to retrieve and display attribution, citation and quotation, references to users (including auto-generation of source reference lists). From laura.lee.carlson at gmail.com Wed May 21 05:21:54 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Wed, 21 May 2008 07:21:54 -0500 Subject: [html4all] Discussion Action 54: First draft of the rewrite of "The img element" In-Reply-To: <1c8dbcaa0805090206y49e7279fyb4898ee61f85ef35@mail.gmail.com> References: <1c8dbcaa0805090206y49e7279fyb4898ee61f85ef35@mail.gmail.com> Message-ID: <1c8dbcaa0805210521j4e58e8c5sa00b99767cdd9fd6@mail.gmail.com> Hi Debi, Thank you very much for your thoughts and comment on the action 54 first draft. It is great that you point out specific text and your rationale behind your proposed change. Much appreciated. Best Regards, Laura On Tue, May 20, 2008, Debi Orton wrote: > Hello, > > I realize that I am late in responding to this thread. Thanks to Steve, > Laura, et. al. for putting this together. > > However, I would like to add my voice to those of the workgroup who have > advocated for requiring an alt attribute for the img element. I work with > several AT users who rely heavily on the alt attribute to find out what > information they may be missing when a page includes images, and I've seen > their frustration when no such information is provided. > > Considering what it provides for those users who need it, it's a small > imposition on developers. > > I have one comment regarding the Complex Data Image advice > (http://esw.w3.org/topic/HTML/Action54AltAttribute#head-2e58ea2dfe69432d96ab13094c0fc96246168e27). > A couple of years back, I was working on a project that posted artwork on > the Internet. The question arose as to whether description would be > meaningful to non-visual people, so I posed it to a listserv of assistive > technology users who provided feedback on web sites from their perspective. > Surprisingly, I heard from several individuals with vision impairments who > said 'yes.' They had been born sighted, and said that given an adequate > description, they were able to visualize the posted artwork. > > My reason for sharing that anecdote is that the heading for that section is > "Complex Data Images" seems to imply that the only complex images that > warrant a detailed description are those representing the interpretation of > data. I suggest that non-data-dependent complex images should also be > included. > > Debi Orton/oradnio at gmail.com -- Laura L. Carlson From laura.lee.carlson at gmail.com Wed May 21 05:23:18 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Wed, 21 May 2008 07:23:18 -0500 Subject: [html4all] Discussion Action 54: First draft of the rewrite of "The img element" In-Reply-To: <1c8dbcaa0805090206y49e7279fyb4898ee61f85ef35@mail.gmail.com> References: <1c8dbcaa0805090206y49e7279fyb4898ee61f85ef35@mail.gmail.com> Message-ID: <1c8dbcaa0805210523ra84b3b6ga947dfda77d9461f@mail.gmail.com> Hi Jon, Thank you for letting us know your thoughts on the first draft of action 54 and for being specific in your comments. We will certainly take your input into consideration and appreciate you taking the time to write. Best Regards, Laura On Tue, May 20, 2008, Jon Barnett wrote: > There are a couple use cases that have been discussed in depth on this > lists but are omitted in this proposal: > > a) An image that is vital to content but its logical alternate text > would be redundant: > >
> > My dog, Bubbles, digging in the > sand on the beach. >
> > Surely alt="" would be incorrect - that would imply that the image is > meaningless, just like an image that is "Purely Decorative" > > b) An image that is vital to content (such as a gallery image) for > which the user simply did not provide text out of laziness: > > > > If the user's tool generates alt="", that would imply that the image > is meaningless. If the user's tool omits alt, the page's HTML is > invalid the semantics are left undefined. The current HTML5 draft > defines semantics for this case and UAs can use. > > The current HTML5 draft handle both of those use cases in a better > manner by just omitting the alt attribute and still covers all the > other use cases in this proposal. > > -- > Jon Barnett > > -- Laura L. Carlson From joshue.oconnor at cfit.ie Wed May 21 06:03:36 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Wed, 21 May 2008 14:03:36 +0100 Subject: [html4all] Issues for the Issue-tracker In-Reply-To: References: Message-ID: <48341DA8.6080504@cfit.ie> Hi Rob, Many thanks for this extensive list of issues. I look forward to discussing them. This list is a good place for this work where ideas can be worked out and an informed front can then approach the wider WG. Cheers Josh From jfoliot at stanford.edu Wed May 21 10:28:26 2008 From: jfoliot at stanford.edu (John Foliot - Stanford Online Accessibility Program) Date: Wed, 21 May 2008 10:28:26 -0700 Subject: [html4all] I wonder what they would say about the current @alt debate... Message-ID: <007301c8bb68$15ac85c0$e53d42ab@stanford.edu> Court rules paper money unfair to blind: "The United States acknowledges that the design hinders blind people but it argued they had adapted -- some relied on store clerks for help, some used credit cards and others folded certain corners to help distinguish the bills. But the U.S. Court of Appeals for the District of Columbia Circuit ruled 2-1 that such adaptations were insufficient. The government might as well argue that, since handicapped people can crawl on all fours or ask for help from strangers, there's no need to make buildings wheelchair accessible, the court said." http://money.cnn.com/2008/05/20/news/blind_money.ap/index.htm JF From foliot at wats.ca Thu May 22 09:50:19 2008 From: foliot at wats.ca (John Foliot) Date: Thu, 22 May 2008 09:50:19 -0700 Subject: [html4all] HTML Action Item 54 - ...draft text for HTML 5 spec to require producers/authors to include @alt on img elements. In-Reply-To: <48356F40.1010308@lachy.id.au> Message-ID: <005d01c8bc2b$f0114b60$dd3c42ab@stanford.edu> Lachlan Hunt wrote: > Optimising for edge cases is not a reasonable thing to do. > Well then, making @alt optional in the edge case of Flickr or an inkblot test is then moot. Those edge cases will remain non-conformant, and @alt as a mandatory requirement is a sealed deal, as optimising for edge cases is not a reasonable thing to do. Right? JF From foliot at wats.ca Thu May 22 12:55:26 2008 From: foliot at wats.ca (John Foliot) Date: Thu, 22 May 2008 12:55:26 -0700 Subject: [html4all] HTML Action Item 54 - ...draft text for HTML 5 spec to require producers/authors to include @alt on img elements. In-Reply-To: <4835AE57.8040903@andrewsidwell.co.uk> Message-ID: <007501c8bc45$c958e270$dd3c42ab@stanford.edu> Andrew Sidwell wrote: > John Foliot wrote: >> Lachlan Hunt wrote: >>> Optimising for edge cases is not a reasonable thing to do. >>> >> >> Well then, making @alt optional in the edge case of Flickr or an >> inkblot test is then moot. Those edge cases will remain >> non-conformant, and @alt as a mandatory requirement is a sealed deal, >> as optimising for edge cases is not a reasonable thing to do. > > Flickr is hardly an edge case. > > Andrew Sidwell Andrew, While I can concede that Flickr is a very large website with hundreds of thousands of users (millions?), in-and-of-it's-self it is but one web site/application owned and operated by Yahoo!. The number of similar photo sharing sites on the web are miniscule to the number of web sites on the web, and the draft spec currently reads: "In certain /rare/ cases, the image is simply a critical part of the content, and there might even be no alternative text available. This could be the case, for instance, in a photo gallery..." Current supporters of the optional @alt often refer to this as the edge-case exception, not I. Wikipedia provides the following definition: "An edge case is a problem or situation that occurs only at an extreme (maximum or minimum) operating parameter." [http://en.wikipedia.org/wiki/Edge_case] and Merriam-Webster's dictionary defines "rare" as: "superlative or extreme of its kind" [http://tinyurl.com/5kj7fm] Given the rarity (quantity of unique sites, not unique users) of photo-sharing sites (which BTW, *could* include the ability to provide @alt, but currently do not do so) and the even rarer instances of Rorschach inkblot tests on the web, it becomes an exercise in semantics to define edge-case here. JF From rob at robburns.com Sun May 25 10:26:08 2008 From: rob at robburns.com (Robert J Burns) Date: Sun, 25 May 2008 17:26:08 +0000 Subject: [html4all] pronunciation, homophones, and homographs Message-ID: <927DC7A5-6D00-4B14-9849-589F1B395CAB@robburns.com> Hello 4all, [apologies for the long email] I've been doing some thinking about aural pronunciation of HTML and homophones and homographs for some time now. My thinking on this is much rawer and less refined than the other issues I've been compiling so I thought I'd solicit some direct feedback from this group and generate some discussion. First, I want to address the issue of markup for pronunciation of unusual or newly introduced terms and abbreviations. Second, I want to address the possibility of markup for distinguishing homographs especially when those homographs are pronounced differently. So here are some of my thoughts on the topic: 1) My first thought is a bit off the topic of HTML5, but I think its important nonetheless. I have long wondered whether Unicode should have a separate block of characters just for phonemes (independent of the the latin script, the International phonetic alphabet, or any other phonetic alphabet). Right now, the International Phonetic Alphabet dominates Unicode which ? despite its name ? is a collection of graphemes largely from the Latin script that correspond one-to-one to each of the linguist identified phonemes. Not only is the IPA latin centered in terms of script, but its really an English language centered phonetic alphabet as well (in that the mnemonic employed are based on the most common English phonetic usage of these letters of the alphabet). Instead, I was thinking we might introduce a separate block of phoneme characters that were glyph (even grapheme) independent. For example a voiced bilabial plosive is represented by the IPA by a 'p' and in unicode as the "Latin Letter P" (U+0070). What I'm suggesting is that this phoneme should have its own code assignment separate from a "Latin Letter P". Among other things this would facilitate the development of other truly international phonetic alphabets (where the mnemonic glyph representing the phoneme is drawn from the language of the authors and readers of the phonetic alphabet). This would represent a departure from the usual Unicode practice of having a representative glyph for every character. For these phonemes, the glyph would depend entirely on the specification of another standard (e.g.: IPA, Americanist phonetic notation, Hebrew Phonetic Alphabet) Among other things, I think this would represent a major shift in mindset to raise awareness of the importance of aurally centered character encoding. Space is quickly running out in the basic multilingual plane (BMP) which facilitates character encoding storage with only 16 bits for each character (therefore these characters would take up 20 to 32 bits of drive storage per character), however, I don't think its a major issue because these phoneme characters would not be stored as much nor as often as other characters. 2) Second, I think its important to provide authors of semantic HTML documents the ability to add pronunciation information for abbreviated forms, newly introduced terms, unusual terms, and homographs. While CSS might be an appropriate place to control the level of chatter and verbosity involving pronunciation (i.e., expanded pronunciation of abbreviations or short-form pronunciations of abbreviations), the semantically relevant pronunciation belongs in the HTML document itself. a) one way to do this would be to introduce a phoneme attribute ? especially for the ABBR, DFN, VAR elements (and the proposed PN and TERM elements). This attribute would accept IPA or eventually the newly introduced Unicode phoneme script characters. This would be a very flexible and powerful approach offering authors complete facilities to specify pronunciations. However, one drawback is that knowledge of IPA and other phonetic alphabets is somewhat specialized and many authors may not be equipped to use this approach b) to address this, another approach would be to add a homophone attribute. This way authors could specify a homophone for a term in a way that didn't involve knowledge of a phonetic alphabet. For example: SQL or SQL This permits authors to add rough pronunciations to their documents with out intimate knowledge of IPA or other phonetic alphabets. 3) This approach got me thinking a bit about homographs and their pronunciation (and other machine processing) as well. I think some authors (especially for archival documents or those who really want to provide complete aural support) may want to provide further semantic encoding of homographs that could facilitate pronunciation and other machine processing. So adding to the homophone example in the previous thought, I was thinking we could add a homograph attribute to distinguish among homographs from various languages. This would be especially useful for those homographs that were the same part of speech and those where pronunciation mattered (read, lead, does, wind). I haven't been able to think of pronunciation dependent homographs that are also the same part (e.g., both nouns). My thought for this, then is to have a homograph or hg attribute that accepts namespaced values to differentiate homographs. Perhaps something like:

Looking at the herd of deer across the prairie, Joe said: I said how does that buck do that with those does

This would require identifying and building an inventory of homographs that could be identified with this attribute. Perhaps a new initiative could get a private dictionary to contribute their copyrighted data or perhaps something from the public domain. My example, supposes that perhaps that a snapshot of Oxford American Dictionary?s homograph rankings, as of a certain date, is made available for use as a value for this attribute. In addition, HTML5 could automatically set the namespace for the HTML5 scope as xmlns:oxford=''. This may be a difficult part of the proposal to achieve. Also it needs to facilitate more internationalization than this example suggests. However, it does not matter so much the actual ordering of the homographs as much as being able to specifically identify which of the several homograph is being used in that place in the document. If HTML had such an associated listing of ranked homographs, then this same listing could be used for the homophone attribute as well. For example: DUZ Any thoughts? Also I'd appreciate any other examples of pronunciation dependent homographs (especially where they are the same part of speech because that makes machines processing very difficult). This may be a fairly specialized use case, but it strikes me as something worthwhile: especially for HTML documents for archival purposes. In addition, I think authoring tools could assist authors in identifying key situations where homograph markup would be important to include even for casual everyday HTML like blogs and the like. Take care, Rob From P.Taylor at Rhul.Ac.Uk Sun May 25 14:58:10 2008 From: P.Taylor at Rhul.Ac.Uk (Philip TAYLOR (Ret'd)) Date: Sun, 25 May 2008 22:58:10 +0100 Subject: [html4all] pronunciation, homophones, and homographs In-Reply-To: <927DC7A5-6D00-4B14-9849-589F1B395CAB@robburns.com> References: <927DC7A5-6D00-4B14-9849-589F1B395CAB@robburns.com> Message-ID: <4839E0F2.8060004@Rhul.Ac.Uk> Robert J Burns wrote: > Hello 4all, > > [apologies for the long email] > > I've been doing some thinking about aural pronunciation of HTML and > homophones and homographs for some time now. [long snip] An interesting and provocative article, Rob : congratulations ! I'll bounce some of your ideas off some of my non-native-speaker (of English) linguist friends and feed back any comments they may have. ** Phil. From rob at robburns.com Sun May 25 16:09:03 2008 From: rob at robburns.com (Robert J Burns) Date: Sun, 25 May 2008 23:09:03 +0000 Subject: [html4all] pronunciation, homophones, and homographs In-Reply-To: <4839E0F2.8060004@Rhul.Ac.Uk> References: <927DC7A5-6D00-4B14-9849-589F1B395CAB@robburns.com> <4839E0F2.8060004@Rhul.Ac.Uk> Message-ID: Hi Philip, On May 25, 2008, at 9:58 PM, Philip TAYLOR (Ret'd) wrote: > > > Robert J Burns wrote: >> Hello 4all, >> >> [apologies for the long email] >> >> I've been doing some thinking about aural pronunciation of HTML and >> homophones and homographs for some time now. [long snip] > > An interesting and provocative article, Rob : congratulations ! > I'll bounce some of your ideas off some of my non-native-speaker > (of English) linguist friends and feed back any comments they > may have. Thanks for the reply. That's certainly a point-of-view I'd like to hear form. suppose in many ways English has a greater need for a separate phonetic alphabet than other languages, but when someone wants to encode phonemes from languages other than their primary language, it makes sense to me that they would want to use graphemes derived from their own familiar primary language. One example I can think of is even the use of a Latin Letter H for an unvoiced glottal fricative which matches how that letter is often used in English. However, for someone whose primary language is Spanish a Latin letter J may make a better mnemonic. Likewise for speakers of Arabic, Urdu, Korean, Hebrew, etc. Using appropriate mnemonic graphemes for each language makes the use of a phonetic alphabet easier and more likely to be widely adopted. Another important issue is that phonetic alphabets change over time ? sometimes swapping one grapheme for another in the representation of a particular phoneme. By encoding the phonemes themselves (and not the graphemes representing the phonemes), the changes to a phonetic alphabet can be handled by updating fonts while maintaining the text document completely unchanged. Similarly, a user can change from one phonetic alphabet to another simply by changing fonts (like from the IPA to the Uralic Phonetic Alphabet). Also, input systems can be localized to the users needs so that a user may use their usual keyboard or a character input palette depicting the graphemes familiar to their primary language even while the input system is actually inputing phoneme characters and not grapheme characters. Finally, I think this could lead to better international interchange of phoneme text. Every user can view a phoneme text document in the phonetic alphabet they're most familiar with. I open the document on my computer and due to my user defaults, the OS automatically associates an IPA font with the phonemes and I see IPA phonetic alphabetic graphemes. However, someone else opens the same document and they see the graphemes corresponding to the phonetic alphabet for their user defaults. For others, they simply hear the synthesized speech uttering the phonemes. As I said before this is a departure for Unicode that I expect would face some resistance. Unicode has, up until now, been focussed exclusively on encoding graphemes as characters: they might have trouble even thinking about a character as a phoneme (and not a grapheme). However, I think this is a natural evolution for Unicode and since it wouldn't need to use any of the precious basic multilingual plane code points, it shouldn't be much of a burden to devote maybe 512 code points to phonemes out of the 800 thousand code points still available for assignment in Unicode. Take care, Rob From P.Taylor at Rhul.Ac.Uk Mon May 26 03:21:44 2008 From: P.Taylor at Rhul.Ac.Uk (Philip TAYLOR (Ret'd)) Date: Mon, 26 May 2008 11:21:44 +0100 Subject: [html4all] pronunciation, homophones, and homographs In-Reply-To: References: <927DC7A5-6D00-4B14-9849-589F1B395CAB@robburns.com> <4839E0F2.8060004@Rhul.Ac.Uk> Message-ID: <483A8F38.4050702@Rhul.Ac.Uk> Robert J Burns wrote: > Thanks for the reply. That's certainly a point-of-view I'd like to > hear form. suppose in many ways English has a greater need for a > separate phonetic alphabet than other languages, Not really : consider Chinese (Pinyin, BoPoMoFo) and Japanese (Hiragana, Katakana) -- when a language is based on ideographs, a phonetic alphabet is /essential/ for descriptive / pedagogic purposes ... > but when someone > wants to encode phonemes from languages other than their primary > language, it makes sense to me that they would want to use graphemes > derived from their own familiar primary language. Yes, that is the idea I wanted to bounce off my Chinese friends. It is not /certain/ that they are in any way unhappy with the IPA as-is, so I would be interested to learn their point of view. (They are all teachers of Chinese as a second language). One example I can > think of is even the use of a Latin Letter H for an unvoiced glottal > fricative which matches how that letter is often used in English. > However, for someone whose primary language is Spanish a Latin letter > J may make a better mnemonic. Likewise for speakers of Arabic, Urdu, > Korean, Hebrew, etc. Agreed. Using appropriate mnemonic graphemes for each > language makes the use of a phonetic alphabet easier and more likely > to be widely adopted. Less certain of that : the IPA has /very/ widespread takeup. > Another important issue is that phonetic alphabets change over time ? > sometimes swapping one grapheme for another in the representation of a > particular phoneme. By encoding the phonemes themselves (and not the > graphemes representing the phonemes), the changes to a phonetic > alphabet can be handled by updating fonts while maintaining the text > document completely unchanged. Agreed. Similarly, a user can change from one > phonetic alphabet to another simply by changing fonts (like from the > IPA to the Uralic Phonetic Alphabet). Also true. Also, input systems can be > localized to the users needs so that a user may use their usual > keyboard or a character input palette depicting the graphemes familiar > to their primary language even while the input system is actually > inputing phoneme characters and not grapheme characters. A good point. > Finally, I think this could lead to better international interchange > of phoneme text. Every user can view a phoneme text document in the > phonetic alphabet they're most familiar with. OK, but what we need here is evidence that the IPA as-is is not the phonetic alphabet with which some users are most familiar. I suspect that Chinese / Japanese academics are very familiar with the IPA, whilst "normal" Japanese / Chinese citizens are far more familiar with Katakana/Hiragana/Pinyin/BoPoMoFo. > For others, they simply hear the synthesized > speech uttering the phonemes. This last point is important, but can that not already be accomplished using Unicode/IPA ? > As I said before this is a departure for Unicode that I expect would > face some resistance. Unicode has, up until now, been focussed > exclusively on encoding graphemes as characters: they might have > trouble even thinking about a character as a phoneme (and not a > grapheme). However, I think this is a natural evolution for Unicode > and since it wouldn't need to use any of the precious basic > multilingual plane code points, it shouldn't be much of a burden to > devote maybe 512 code points to phonemes out of the 800 thousand code > points still available for assignment in Unicode. Definitely unsure you can express the world's phonemic collection in 512 slots ! But the departure (for Unicode) is so radical that I fear it is doomed from the outset, which is (a) why I'd like the input of non-Latin native speakers, and (b) to consider whether (if they agree that the IPA is sub-optimal) whether we can find a way to express phonemes without requiring a change to Unicode. Remember that both the IPA and Unicode have a /very/ well established user-base; we are even more of an edge-case than Flicker in this context :-) ** Phil. From rob at robburns.com Mon May 26 04:10:38 2008 From: rob at robburns.com (Robert J Burns) Date: Mon, 26 May 2008 11:10:38 +0000 Subject: [html4all] pronunciation, homophones, and homographs In-Reply-To: <483A8F38.4050702@Rhul.Ac.Uk> References: <927DC7A5-6D00-4B14-9849-589F1B395CAB@robburns.com> <4839E0F2.8060004@Rhul.Ac.Uk> <483A8F38.4050702@Rhul.Ac.Uk> Message-ID: <241EF8D7-721A-4F22-8FDC-D4E25613B6F3@robburns.com> Hi Phil, Thanks for the feedback on the Unicode phonetics idea. Just a few things I want to say to help you understand my motivation here. First, I'm not trying to supplant the IPA or suggest it is suboptimal. It is certainly a widely adopted and effective phonetic alphabet. Second, my interest in facilitating other phonetic alphabets is not so much for those who speak/hear/readwrite English as a second language, but for those who have little or no familiarity with written English at all. Imagine, for example, a person from an Arabic speaking country who never learned English or any of the languages written using the Latin script. Perhaps this is becoming more rare (especially among academics) but I'm also interested in facilitating use of phonetic alphabets by non-academics (at least a reading and writing literacy for phonemes). You do make a good point regarding the need for a phonetic alphabet for languages that use ideographs. However, in that case my goal is also undermined, since the ability to develop phonetic graphemes that are mnemonically familiar to the native reader of such a language is already a problem. I agree that the IPA Unicode characters already facilitate speech synthesis. My thinking on this is that it is much more an enhancement to internationalization of phoneme characters than it is about aural rendering and accessibility of phonemes. Different users are familiar with different phonetic alphabets and encoding abstract semantic phonemes allows for effective separation of semantics and grapheme presentation. So part of my motivation is also to facilitate wider international comprehension of phonetic alphabets so that they become more common place and in that way facilitate accessibility. Finally, my estimate of 512 code points is a liberal estimate based on the current needs of the IPA and other phonetic alphabets. The number could even be reduced by using character combinations (such as voiced or voiceless modifiers) to modify the previous character. I think I came up with one character / code point mapping that required only 64 characters for all phonemes (I was trying to make it fit somewhere in the BMP). Again, I really appreciate your feedback. Take care, Rob On May 26, 2008, at 10:21 AM, Philip TAYLOR (Ret'd) wrote: > > > Robert J Burns wrote: > >> Thanks for the reply. That's certainly a point-of-view I'd like to >> hear form. suppose in many ways English has a greater need for a >> separate phonetic alphabet than other languages, > > Not really : consider Chinese (Pinyin, BoPoMoFo) and > Japanese (Hiragana, Katakana) -- when a language is based > on ideographs, a phonetic alphabet is /essential/ for descriptive > / pedagogic purposes ... > >> but when someone >> wants to encode phonemes from languages other than their primary >> language, it makes sense to me that they would want to use graphemes >> derived from their own familiar primary language. > > Yes, that is the idea I wanted to bounce off my Chinese friends. > It is not /certain/ that they are in any way unhappy with the > IPA as-is, so I would be interested to learn their point of > view. (They are all teachers of Chinese as a second language). > > One example I can >> think of is even the use of a Latin Letter H for an unvoiced glottal >> fricative which matches how that letter is often used in English. >> However, for someone whose primary language is Spanish a Latin letter >> J may make a better mnemonic. Likewise for speakers of Arabic, Urdu, >> Korean, Hebrew, etc. > > Agreed. > > Using appropriate mnemonic graphemes for each >> language makes the use of a phonetic alphabet easier and more likely >> to be widely adopted. > > Less certain of that : the IPA has /very/ widespread takeup. > >> Another important issue is that phonetic alphabets change over time ? >> sometimes swapping one grapheme for another in the representation >> of a >> particular phoneme. By encoding the phonemes themselves (and not the >> graphemes representing the phonemes), the changes to a phonetic >> alphabet can be handled by updating fonts while maintaining the text >> document completely unchanged. > > Agreed. > > Similarly, a user can change from one >> phonetic alphabet to another simply by changing fonts (like from the >> IPA to the Uralic Phonetic Alphabet). > > Also true. > > Also, input systems can be >> localized to the users needs so that a user may use their usual >> keyboard or a character input palette depicting the graphemes >> familiar >> to their primary language even while the input system is actually >> inputing phoneme characters and not grapheme characters. > > A good point. > >> Finally, I think this could lead to better international interchange >> of phoneme text. Every user can view a phoneme text document in the >> phonetic alphabet they're most familiar with. > > OK, but what we need here is evidence that the IPA as-is is not > the phonetic alphabet with which some users are most familiar. > I suspect that Chinese / Japanese academics are very familiar > with the IPA, whilst "normal" Japanese / Chinese citizens are > far more familiar with Katakana/Hiragana/Pinyin/BoPoMoFo. > >> For others, they simply hear the synthesized >> speech uttering the phonemes. > > This last point is important, but can that not already > be accomplished using Unicode/IPA ? > >> As I said before this is a departure for Unicode that I expect would >> face some resistance. Unicode has, up until now, been focussed >> exclusively on encoding graphemes as characters: they might have >> trouble even thinking about a character as a phoneme (and not a >> grapheme). However, I think this is a natural evolution for Unicode >> and since it wouldn't need to use any of the precious basic >> multilingual plane code points, it shouldn't be much of a burden to >> devote maybe 512 code points to phonemes out of the 800 thousand code >> points still available for assignment in Unicode. > > Definitely unsure you can express the world's phonemic collection > in 512 slots ! But the departure (for Unicode) is so radical > that I fear it is doomed from the outset, which is (a) why I'd > like the input of non-Latin native speakers, and (b) to consider > whether (if they agree that the IPA is sub-optimal) whether we > can find a way to express phonemes without requiring a change > to Unicode. Remember that both the IPA and Unicode have a > /very/ well established user-base; we are even more of an > edge-case than Flicker in this context :-) > > ** Phil. > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki From chaals at opera.com Mon May 26 04:21:03 2008 From: chaals at opera.com (Charles McCathieNevile) Date: Mon, 26 May 2008 13:21:03 +0200 Subject: [html4all] pronunciation, homophones, and homographs In-Reply-To: <927DC7A5-6D00-4B14-9849-589F1B395CAB@robburns.com> References: <927DC7A5-6D00-4B14-9849-589F1B395CAB@robburns.com> Message-ID: On Sun, 25 May 2008 19:26:08 +0200, Robert J Burns wrote: > 1) My first thought is a bit off the topic of HTML5, but I think its > important nonetheless. I have long wondered whether Unicode should > have a separate block of characters just for phonemes (independent of > the the latin script, the International phonetic alphabet, or any > other phonetic alphabet).... > Among other things, I think this would represent a major shift in > mindset to raise awareness of the importance of aurally centered > character encoding. Not to put too fine a point on it :) In principle it sounds like it could be interesting. In practice I am not sure of the major benefit it offers over using IPA with a custom set of glyphs - I understand that IPA is kind of messy, but I am somewhat unconvinced that "voiced bilabial plosive" is more intuitive than "p" to *anybody*. There is of course the problem that most languages simply don't have a good written representation for most sounds. Languages that are written highly phonetically like Spanish or Japanese don't have a way to express many sounds ("v" - is that a voiced fricative? - isn't distinct from "b" for most Spanish speakers, although those who know something of other languages recognise that it is meant to signify something different sometimes). I would suggest that the Unicode consortium are more likely to take this on than W3C. After all, W3C just uses Unicode, in general, and I don't think there is any interest in them defining anything different - where they have input they tend to take it directly to the Unicode Consortium themselves. > 2) Second, I think its important to provide authors of semantic HTML > documents the ability to add pronunciation information for abbreviated > forms, newly introduced terms, unusual terms, and homographs. While > CSS might be an appropriate place to control the level of chatter and > verbosity involving pronunciation (i.e., expanded pronunciation of > abbreviations or short-form pronunciations of abbreviations), the > semantically relevant pronunciation belongs in the HTML document itself. The SSML phoneme [1] and sub elements attribute is designed to serve this purpose. It is also possible to do this using ruby markup (which I note on the what-wg that Ian has added to the spec - I wish he were a bit more careful about ensuring the W3C working group were kept up to date), and it is also possible to do it using CSS speech properties, in principle. One of the problems that this introduces is that pronunciation is often not that helpful. I have enormous difficulty knowing if americans are saying "can" or "can't" due to their habit of pronouncing the latter like a Norwegian would say "Kant" instead of how one would say "cahnt". And so on and so forth (Roald Dahl wrote a very nice story about someone's American Aunt once, playing on this). [1] http://www.w3.org/TR/speech-synthesis/#edef_phoneme [2] http://www.w3.org/TR/speech-synthesis/#edef_sub > 3) This approach got me thinking a bit about homographs and their > pronunciation (and other machine processing) as well... See also SSML's say-as attribute [3,4] > If HTML had such an associated listing of ranked homographs, then this > same listing could be used for the homophone attribute as well. For > example: > > >DUZ I don't think HTML is going to include a list of homographs. I am certain that we are not going to ship one by default, since for our most important languages this would imply a large amount of extra footprint for a miniscule amount of gain. Shipping 2000 MathML entities (very short things that can be compressed easily) is already a hassle that we wish we didn't have to deal with. Hoping to get commercially published text given to HTML for free strikes me as something close to wishful thinking, which rules it out for english. Many other languages (French, Spanish, Icelandic, and probably non-European langauges, although I am not sure) have an official definition, so may be available. Whether the official definition is useful on the Web is a moot point. Valencianos will point out that they speak a language, although the Spanish government does not recognise it and the Library of Congress (which manages a list of languages for ISO) apparently has insufficient data - they are known to have collected very poor data for a number of indigenous languages from at least Australia and South America which clearly have sufficient texts to warrant more detailed classification than "aboriginal language of [somewhere]". I would suggest here that you look at the use of Ruby and XHTML+Voice before going further down the path of inventing stuff - these things have been dealt with before. (It turns out that the market for them is fairly restricted, so people don't necessarily know of the solutions that have already been implemented). 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 rob at robburns.com Mon May 26 09:00:38 2008 From: rob at robburns.com (Robert J Burns) Date: Mon, 26 May 2008 16:00:38 +0000 Subject: [html4all] pronunciation, homophones, and homographs In-Reply-To: References: <927DC7A5-6D00-4B14-9849-589F1B395CAB@robburns.com> Message-ID: <41EFC2B2-64CE-4955-80A1-830779772B3A@robburns.com> HI Charles, Thanks for the feedback. On May 26, 2008, at 11:21 AM, Charles McCathieNevile wrote: > On Sun, 25 May 2008 19:26:08 +0200, Robert J Burns > wrote: > >> 1) My first thought is a bit off the topic of HTML5, but I think its >> important nonetheless. I have long wondered whether Unicode should >> have a separate block of characters just for phonemes (independent of >> the the latin script, the International phonetic alphabet, or any >> other phonetic alphabet).... > >> Among other things, I think this would represent a major shift in >> mindset to raise awareness of the importance of aurally centered >> character encoding. > > Not to put too fine a point on it :) > > In principle it sounds like it could be interesting. In practice I > am not > sure of the major benefit it offers over using IPA with a custom set > of > glyphs - I understand that IPA is kind of messy, but I am somewhat > unconvinced that "voiced bilabial plosive" is more intuitive than > "p" to > *anybody*. That is precisely the reason for the proposal. It is intended to facilitate phonetic alphabets (or more broadly phonetic writing systems) where the user and author need not necessarily have an academic?s knowledge of phonetics and phonemes nor also strong knowledge of English or other Latin languages (which are the only ones where ?p? will have any intuitive association with a phoneme) > There is of course the problem that most languages simply don't > have a good written representation for most sounds. Languages that are > written highly phonetically like Spanish or Japanese don't have a > way to > express many sounds ("v" - is that a voiced fricative? - isn't > distinct > from "b" for most Spanish speakers, although those who know > something of > other languages recognise that it is meant to signify something > different > sometimes). Actually, it is not true that most languages don't have a good written representation of most sounds. Most writing systems (non-ideographic ones) are phonetically based (most, more so than English which is such an agglomeration that its phonetic associations are blurred). Rather it is the case that each language is different regarding which phonemes they represent through writing and use in speech. English too has phonemes it does not use and therefore turns to specialized graphemes to represent them in the phonetic alphabet. The same is true for Spanish in that it would not use "v" and "b" in the same way that the English-centric IPA uses "v" and "b". Again, this is to facilitate internationalization/localization of phoneme characters and facilitate the utilization of Unicode for a plurality of phonetic alphabets. Keep in mind also that, though this is a significant change in Unicode (encoding phonemes rather than graphemes), it is also quite consistent with Unicodes project on the whole, where Unicode tries to provide implementation developers with algorithms, data repositories and methods to enhance localization/internationalization. By using one set of phonemes for all phonetic writing systems (meaning those that share the same phoneme classification, e.g: not Kana), interchange of such text data is greatly enhanced. Systems can easily draw glyphs from the appropriate font given a user?s preferences. While another use sees glyphs drawn from a different phonetic writing system for the same text document (likewise for input systems). > I would suggest that the Unicode consortium are more likely to take > this > on than W3C. After all, W3C just uses Unicode, in general, and I don't > think there is any interest in them defining anything different - > where > they have input they tend to take it directly to the Unicode > Consortium > themselves. Certainly. As I said, this first though (1) was a topic not for the HTML WG, but rather related to the other thoughts (2 and 3). Though certainly a liaison from the HTML WG would provide significant weight for the idea. >> 2) Second, I think its important to provide authors of semantic HTML >> documents the ability to add pronunciation information for >> abbreviated >> forms, newly introduced terms, unusual terms, and homographs. While >> CSS might be an appropriate place to control the level of chatter and >> verbosity involving pronunciation (i.e., expanded pronunciation of >> abbreviations or short-form pronunciations of abbreviations), the >> semantically relevant pronunciation belongs in the HTML document >> itself. > > The SSML phoneme [1] and sub elements attribute is designed to serve > this > purpose. It is also possible to do this using ruby markup (which I > note on > the what-wg that Ian has added to the spec - I wish he were a bit more > careful about ensuring the W3C working group were kept up to date), > and it > is also possible to do it using CSS speech properties, in principle. > > One of the problems that this introduces is that pronunciation is > often > not that helpful. I have enormous difficulty knowing if americans are > saying "can" or "can't" due to their habit of pronouncing the latter > like > a Norwegian would say "Kant" instead of how one would say "cahnt". > And so > on and so forth (Roald Dahl wrote a very nice story about someone's > American Aunt once, playing on this). > > [1] http://www.w3.org/TR/speech-synthesis/#edef_phoneme > [2] http://www.w3.org/TR/speech-synthesis/#edef_sub There would certainly be some issues here with localization/ internationalization. However, this part of the proposal was much more focussed on the accessibility and machine processing parts more than the internationalization part like my Unicode suggestion. I'm sorry for causing that confusion. >> 3) This approach got me thinking a bit about homographs and their >> pronunciation (and other machine processing) as well... > > See also SSML's say-as attribute [3,4] Yes, I think that's a good example. Perhaps ?say-as? would be a more appropriate attribute name for an HTML attribute as well. > > >> If HTML had such an associated listing of ranked homographs, then >> this >> same listing could be used for the homophone attribute as well. For >> example: >> >> > >> DUZ > > I don't think HTML is going to include a list of homographs. I am > certain > that we are not going to ship one by default, since for our most > important > languages this would imply a large amount of extra footprint for a > miniscule amount of gain. Shipping 2000 MathML entities (very short > things > that can be compressed easily) is already a hassle that we wish we > didn't > have to deal with. Yes, I understand. I didn't mean to say that HTML5 would compile the list of homographs or that browsing UAs would need to bundle a dictionary of homographs. These are simply meant for authors and authoring tools and so that users of applications that perform machine processing of semantics (including text-to-speech applications) could make use of them. > Hoping to get commercially published text given to HTML for free > strikes > me as something close to wishful thinking, which rules it out for > english. Yeah, I probably shouldn't have used those words. If I had a team of lawyers behind me, they'd be scolding me right now for even saying that. What I meant was that a published dictionary could be used by way of reference: though frozen for a specific edition. If I were the publisher of a dictionary that would be my wildest dream to have the international format for writing documents reference my homographs in their attribute values. > > Many other languages (French, Spanish, Icelandic, and probably > non-European langauges, although I am not sure) have an official > definition, so may be available. Whether the official definition is > useful > on the Web is a moot point. Valencianos will point out that they > speak a > language, although the Spanish government does not recognise it and > the > Library of Congress (which manages a list of languages for ISO) > apparently > has insufficient data - they are known to have collected very poor > data > for a number of indigenous languages from at least Australia and South > America which clearly have sufficient texts to warrant more detailed > classification than "aboriginal language of [somewhere]". I recently read a quote from Stalin that was nevertheless profound. It went something like "The difference between a language and a dialect is that the language has a navy behind it and the dialect does not." :-) It's not important for every last dialect to have a codified rank designation for homographs, but where distinctions exist, the more that do the better. > I would suggest here that you look at the use of Ruby and XHTML+Voice > before going further down the path of inventing stuff - these things > have > been dealt with before. (It turns out that the market for them is > fairly > restricted, so people don't necessarily know of the solutions that > have > already been implemented). Thanks for those suggestions. However, Ruby is definitely not what I'm thinking about with these thoughts. XHTML+Voice also appears much more heavy-weight than I was looking for. Again, the suggestions I'm making (or the thoughts I'm having) relate to a way to facilitate differentiating homographs in HTML for machine processing and pronunciation purposes). These attributes I'm proposing would likely not often have significant visual rending (unlike Ruby) nor even a major role in text-to-speech (as in X+V) or audible web applications. Instead these suggestions simply provide a few simple and easy facilities for authors of documents (typically not web application documents) to make such homograph differentiations and pronunciation specifications where desired. For general browsing UAs, like Opera no additional implementation norms would be involved. Improvements to implementations would only be necessary for those UAs doing the work of differentiating homographs, (though perhaps even those UAs can make most of these distinctions without markup; that's what I'm trying to determine). Again, keep in mind that this proposal is something to benefit users and authors. In general it is costless for implementations, except for those specialized implementations that want to make use of this extra information. The only downside I can see is that adding these few attributes might ? together with adding other facilities ? add too many facilities to HTML and overwhelm authors: especially those authors reading the spec and trying to learn it properly. To me the only way to deal with that concern is to build a draft of the spec with all of these things and then weigh the issue of whether anything can or should be trimmed. Obviously the other issues would surround whether the attributes should have a different name; whether elements would better suit the semantics than attributes; and whether these facilities should be handled by a complimentary technology such as CSS (the separation of concerns). Take care, Rob From foliot at wats.ca Mon May 26 17:17:00 2008 From: foliot at wats.ca (John Foliot) Date: Mon, 26 May 2008 17:17:00 -0700 Subject: [html4all] Is Flickr an Edge Case? (was Re: HTML Action Item 54) In-Reply-To: Message-ID: <008501c8bf8f$0052bcf0$6d01a8c0@stanford.edu> Maciej Stachowiak wrote: > > Word Wide Web traffic is widely believed to follow a power law > distribution (looking at the "reach" statistics for the top 100 sites > is consistent with this hypothesis). This means that the top few sites > likely get as much traffic as the remaining 165 million combined. Keep > in mind also that flickr is a site with billions of pages. It is clear > that by any measure, photo sharing is one of the most popular > activities on the Web. Only search, video sharing, social networking > (which very often includes an aspect of photo sharing), blogging (also > sometimes including an aspect of photosharing) and online shopping > appear to be more or equally popular, as far as one can tell from the > most popular sites and their reach. If one of the most popular > activities on the internet is an "edge case", then what would you > consider to be a valid use case? Given that "photo sharing" is one of the most popular activities on the internet, all the more reason to not leave open the door that suggests that sometimes an image without @alt is "conformant". The constant refrain from the working group is that this would be a rare instance, yet you now suggest that it will be the majority, and not a rare instance at all. If 10 of the top 100 websites on the WWW have this magic get-out-of-jail-free card then surely others will seek to claim the same status. The precedent being suggested here is staggering. This is supposed to "help" accessibility? > > No, that's not the real issue. Accessibility standards are a means to > an end, not an end in itself. The real issue is: what HTML document > conformance requirements are likely to lead to the best accessibility > outcomes, considering all the use cases and possible unintended > consequences and second-order effects? Exactly!! What unintended consequences and second-order effects do you think will emerge once you make @alt optional for a class of sites that claim "special status"? One possible outcome will be that more sites will seek to claim this status, and the overall quantity of images with @alt will diminish. This is a real possible outcome, and to suggest otherwise is simply disingenuous. More and more, we are seeing a new way of "publishing" to the web that removes any actual "coding" by the content author: CMS tools such as Drupal and Joomla (which have embedded editors such as Tiny MCE or FKCEditor), wikis and their kin, and social networking sites such as MySpace and Facebook. If all of these "sites" and authoring methods get to claim "special" status because they have the author upload images (be it 1, or 3,000 vacation photos), where goes accessibility, and how exactly is this a benefit? > Several ways to mark in image in such a manner have been proposed. The > current spec draft proposes: > > Which significant numbers are rejecting as not acceptable so far. Can we accept that as a truth? (Or do we need to conduct a public campaign and gather more dissenting voices to "prove a point"?) > > Other alternatives that have been proposed: > > > > > * > _ > > Interestingly, 4 of the 6 above maintain @alt (and fifth uses alt, as in "noalt"). You also left out the possibility of reserved values for @alt, or my suggestion that should an have one of a possible many means of directly associating a textual equivalent to an image that conformance could be considered - if @alt is not the best solution in a given scenario, is there a different solution that could/would work besides just saying "leave out the @alt"? Once the WG comes to the conclusion that optional @alt as proposed is a non-starter and starts really discussing a different approach, this debate will continue to churn and go round-and-round 'till the cows come home. There have been many off-line comments within the working group about "dogma" emerging from the accessibility camp, but the responses from the other side are equally immobile and dogmatic - simply stating that will improve accessibility will not make it true, no matter how many times you say it. > > They are relevant to whether the use case of embedding images where > alternative content is not available is important to consider. If you > agree that it is, then I agree there is no need to debate the matter. In this there is total agreement. The current proposed method is not acceptable, let's agree to that and start real dialogue on a better way forward shall we? JF From foliot at wats.ca Mon May 26 17:38:15 2008 From: foliot at wats.ca (John Foliot) Date: Mon, 26 May 2008 17:38:15 -0700 Subject: [html4all] pronunciation, homophones, and homographs In-Reply-To: <4839E0F2.8060004@Rhul.Ac.Uk> Message-ID: <008601c8bf91$f3d70fa0$6d01a8c0@stanford.edu> Philip TAYLOR (Ret'd) wrote: > Robert J Burns wrote: >> Hello 4all, >> >> [apologies for the long email] >> >> I've been doing some thinking about aural pronunciation of HTML and >> homophones and homographs for some time now. [long snip] > > An interesting and provocative article, Rob : congratulations ! I'll > bounce some of your ideas off some of my non-native-speaker (of > English) linguist friends and feed back any comments they may have. > Rob, I echo Philip's comments and will bring this up with some of my associates on campus, especially those in the languages dept. - they may have some ideas regarding alternate pronounciation dictionaries, etc. JF From rob at robburns.com Mon May 26 19:25:12 2008 From: rob at robburns.com (Robert J Burns) Date: Tue, 27 May 2008 02:25:12 +0000 Subject: [html4all] Issue-tracker Issues Message-ID: Hello 4all, I originally tried sending the issues I want Gregory to add to the issue tracker as separate emails, thinking it would make discussion easier. After doing so and accidentally duplicating some messages, I now think it would be good to combine them all in a single email for easy URI referencing (plus I've compiled together more issues than I had before). Most of these were distilled from discussion in the first 6 months of the life of the WG. Many are issues that I think should be addressed by HTML5, but were often dismissed by Ian and many from the WhatWG. Many have direct accessibility benefits, but they also touch upon using HTML for archival purposes, academic documents (e.g., an online encyclopedia) and in many ways rounding out the facilities of HTML. For example, the implementation of a few of the features raised in these issues would provide support within HTML documents and HTML UAs to automatically generate (according to UA, author or user stylesheets): ? A bibliographic source reference list (see [7]) ? end notes / footnotes (see [6]) ? A glossary of terms (see [8]) ? An index of subjects (see [8]) ? An index (or indexes) of names (authorities, proper nouns, etc.) (see [8]) These would be in addition to the automatic generation of a table of contents already proposed for HTML5. Of course once these semantics are encoded within an HTML document, the presentation of this data can also take on new forms and not just rely on the forms used in traditional printing of documents. Many of these features would serve he use case of sites such as Wikipedia which now have to provide these features awkward server-side scripts rather than client-side UA processing. Again, I welcome feedback on these, either here, on the WG list or by improving the associated wiki pages. If anyone wants to recommend improved language for the summaries of these issues that would be good too. It may be that I've too deeply reflected on these topics to adequately summarize them for the uninitiated. Also please feel free to visit the wiki pages and add supporting discussions, emails and improved language. Some of the wiki pages are in a rather raw form, but I hope to clean them up over the next few days. If those of you attending the HTML teleconf can raise these issues and advocate for them, I would greatly appreciate it. Though I cannot usually attend the teleconferences, any of you may volunteer my time to draft language for the HTML5 recommendation for these issues. I think the few issues in this list that involve adding new elements ([4] [6] and [8]) to HTML5 should be treated as the highest priority and get into the draft as soon as possible (including the minor changes needed to the parsing algorithm). The issues listed here in this email constitute the bulk of the issues I've identified in the first half-year of the WG. There are a few other more minor issues, but they are all much lower priority than these. I will likely post these to the HTML4all and the WG email lists as separate emails to facilitate discussion both there and here. Take care, Rob ------------- The proposed issue-tracker Issues (with endnotes referencing the relevant wiki page): ------------- ? Add a document authoring requirement to designate role for embedded content. To ease the burden on authoring tools and authors, and to provide further information for UAs and users unable to consume non- text media provide an attribute and HTML specified attribute NCNames for designating the role of non-text media.[1] ? For Q (quotation) and BLOCKQUOTE a 'marks' content markup attribute. Permits authors greater control over the separation of concerns of styling quotations and specifying the semantics of quotations within a document. Also allows authors to work around the current state of interoperability across popular UAs.[2] ? Enhanced client-side Image Maps. Provide more complete specification of client-side image maps to improve accessibility and general usability and also entirely eliminate the need for server-side image map processing.[3] ? Markup support for bookmark and clipping support of documents. Provides a way to markup specific points within a document or contiguous sections of a document that may not be hierarchically well- formed (such as the pages of an archival document that may contain portions of a paragraph).[4] ? Pronunciation attributes for abbreviations, variables, proper nouns and terms. Adds phonetic and related pronunciation attributes for DFN, ABBR, VAR and proper names. Adds a phonetic attribute to several elements as well as type and expressedas attributes to the ABBR element.[5] ? Cross-referencing and subtext. To provide semantic features in HTML5 supporting proposed styling features in CSS3 and because authors have an independent need to markup notes and cross references regardless of presentation.[6] ? Markup improvements and UA norms to associate attributions, citations, quotations and references. Adds some attributes for pages, annotations and ordered and unordered reference lists and UA norms to retrieve and display attribution, citation and quotation, references to users (including auto-generation of source reference lists)[7] ? Definitions and Abbreviations cross-referencing. Provide a more complete and compact markup syntax for associating definitions, terms, variables, proper names and abbreviated forms. Also promote greater user enhancements within UA implementations for such semantics by automatically generating document subject and name indexes, glossaries and interactive UI for these semantics.[8] ? Support for eliminating authoring distinctions between block and non- block semantics (particularly within the HTML5 DOM and XML serialization, but perhaps also in text/html serialization) Proposal would allow authors to use only Q element and not need to worry about Q and BLOCKQUOTE distinctions (also could apply to CODE and BLOCKCODE if HTML5 adopted these semantics).[9] ? Add a new IDENT data type for the id attribute and clearly specify the CSS selector and DOM method processing for xml:id of type ID and id of type IDENT (helps facilitate compound documents and current authoring practice).[10] ? CSS and DOM support and new UA norms for associating data cells and header cells in tables.[11] ? Meta and HTTP redirect UA norm to improve accessibility and general usability.[12] ? Add MediaElement, VIDEO and AUDIO related features to the OBJECT element.[13] ? UAs should provide rich UI to access document data (title, href, cite, longdesc, aria-describedby, alt, ).[14] ? Support for a new cascading keyboard key binding mechanism.[15] ? Menu commands in the menu bar providing author access for arranging ordered menu bar menus (for better web application support).[16] ? Mechanism for expressing the semantics of styling (e.g., "[red letters] indicate [the words of Jesus]").[17] ? New attributes for handling and downloading linked and embedded resources.[18] ? ALT element or alternate list and other new mechanisms for delivering alternate content to users (in addition to content negotiation and rel='alternate' on the LINK and A elements).[19] ? UA language content-negotiation norms (presenting users with choices for multilingual users and whenever appropriate).[20] ? UA norm for DOM API to return the element containing the script and a re-implementation of document.write using this method.[21] ? UA norm to expose the metadata properties of non-text media.[22] Links: [1]: [2]: [3]: [4]: [5]: [6]: [7]: [8]: [9]: [10]: [11]: [12]: [13]: [14]: [15]: [16]: [17]: [18]: [19]: [20]: [21]: [22]: From faulkner.steve at gmail.com Tue May 27 02:30:50 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Tue, 27 May 2008 10:30:50 +0100 Subject: [html4all] Is Flickr an Edge Case? (was Re: HTML Action Item 54) In-Reply-To: References: <008501c8bf8f$0052bcf0$6d01a8c0@stanford.edu> Message-ID: <55687cf80805270230u2e8742e1id51cb4df70573915@mail.gmail.com> hi maciej >Ironically, a number of proposals other than simply omitting alt have been made, >including by the Editor, and they have been completely ignored by the >accessibility camp, as far as I can tell. John foliot and I have both made a number of proposals [1] that have been generally ignored by the editor , as far as i can tell. Both of us could be considered as being in the 'accessibility camp' or to put it another way, the 'non-whatwg camp'. I have noted the mention of a proposal by the editor, but have not been able to find it, a pointer would be useful. [1]http://lists.w3.org/Archives/Public/public-html/2008May/0443.html regards stevef From laura.lee.carlson at gmail.com Tue May 27 04:54:28 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Tue, 27 May 2008 06:54:28 -0500 Subject: [html4all] Is Flickr an Edge Case? (was Re: HTML Action Item 54) In-Reply-To: References: <008501c8bf8f$0052bcf0$6d01a8c0@stanford.edu> Message-ID: <1c8dbcaa0805270454j78faf447n738a32f0e1a6f6a8@mail.gmail.com> Hi Maciej, > Ironically, a number of proposals other than simply omitting alt have been made, > including by the Editor, and they have been completely ignored by the accessibility > camp, as far as I can tell. If there are any potential solutions missing from the Wiki page on this issue [1], please do add them. Thanks. Best Regards, Laura [1] http://esw.w3.org/topic/HTML/IssueAltAttribute#head-27468e7ee9afd1f9e07186c8d74f0b0168b3975a -- Laura L. Carlson From foliot at wats.ca Tue May 27 10:36:57 2008 From: foliot at wats.ca (John Foliot) Date: Tue, 27 May 2008 10:36:57 -0700 Subject: [html4all] Is Flickr an Edge Case? (was Re: HTML Action Item 54) In-Reply-To: <20080527005935.GA30490@pickering.dbaron.org> Message-ID: <00f501c8c020$44a85c70$6d01a8c0@stanford.edu> L. David Baron wrote: > > Applying all the requirements we apply to mass media to content > creation for small audiences doesn't make sense. We have to consider > the costs and benefits of meeting these requirements. If we enforce > them on everyone, one thing we'll do is force a lot of this content > off of the Web entirely, which would make it accessible to much fewer > people. This is not what is being debated here however. What is being suggested is that the technical specification be written to open a loop-hole that so far has been closed: images must contain @alt if they are to be deemed conformant. That millions of images lack @alt, or a valuable @alt value is not open to discussion - I will concur that they exist. This alone is not a reason to reverse the course and suggest that it's somehow OK, so we'll re-write the spec to say that it is. It's not. Since the current penalty for not having @alt is... NOTHING... I cannot see how the new spec helps anyone save those who want conformant code without doing all that is required to ensure conformance. We are talking about a technical specification here: black and white rules that establish how to be conformant. Sites and authors will then chose to be conformant or be non-conformant. Sites such as Flickr - if they *want* to be conformant, will do what they can to ensure that from a "code" perspective they are outputting correct code: if a code fragment requires a string from an external author, that is beyond their control, but if the conformance requirement exists that an attribute must exist, they can at least ensure that the placeholder exists and a means to provide a value for that attribute is present. Today, for a web page to be "conformant" the specification calls for a DTD. No DTD, not conformant. Yet Google's pages have no DTD, and their web pages "work" just fine: Google made a choice and that is theirs to make, but since arguably *the* most visited webpage on the internet today is non-conformant, then why are we insisting, even in HTML 5, for a DTD? There is no "technical" reason to reverse the requirement for a mandatory @alt save that it makes it easier to have conformant pages. It does nothing to improve accessibility, it does nothing to enhance or improve the next generation of HTML, it does nothing for the very people who most need to have a textual alternative to an image. If, as suggested, most photos are viewed by a very few (your telephone analogy), then what is wrong with adding alt="" to those millions of images viewed by the very few? The whole argument falls flat on it's face. JF From foliot at wats.ca Tue May 27 10:37:37 2008 From: foliot at wats.ca (John Foliot) Date: Tue, 27 May 2008 10:37:37 -0700 Subject: [html4all] Is Flickr an Edge Case? (was Re: HTML Action Item 54) In-Reply-To: Message-ID: <00f601c8c020$5af8f250$6d01a8c0@stanford.edu> Maciej Stachowiak wrote: > > I am not sure it is in good taste to liken accessibility markup to > being in jail. That being said, the current draft allows alt to be > omitted based on the nature and context of the image (i.e. does the > person or tool generating the HTML know what the image is), not based > on the nature of the site. Oh-My-God! I will give you the benefit of the doubt and presume you are unaware of the "expression" I used - in this case a reference to the board game Monopoly, whereby you get a card or pass so that you need not suffer consequences (sitting out your turn), and instead allows you to continue to play as if nothing is/was wrong. It has nothing to do with going to jail (any more than landing your player token on the second corner of the Monopoly game board), and has everything to do with individuals or entities skirting their responsibility by invoking the "photo-upload" scenario, thereby avoiding doing what the specification states they must do, except in rare (or now apparently not so rare) circumstances. The fact that it has evolved from rare instances to some of the most popular sites on the web today in the space of less than a dozen emails simply serves to illustrate the severity of the potential loophole. > > I don't believe anyone has proposed site-based special status. No, instead it is by instance - and now it encompasses millions of web pages, by your own calculations. And yet some want a spec that, by it's writing, practically encourages these sites to avoid adding @alt values - they don't need to, they are photo-upload sites: "In certain rare cases, the image is simply a critical part of the content, and there might even be no alternative text available. This could be the case, for instance, in a photo gallery..." [http://www.w3.org/TR/html5/#the-img] (By my exact reading, this suggests that a photo-gallery site might have this "special status" - these are not my words, they are directly quoted from the draft spec.) > > Regardless of the markup used, it is not reasonable to expect an > ordinary person to provide alternative text when bulk-uploading > thousands of vacation photos. In the real world, I know of nobody who takes "thousands" of vacation photos, and then bulk uploads them in one single instance. Ian once asked if the number was an issue, knowing full well that it is not. Is there a magic line: upload less than this number and you *must* include @alt, but exceed that number by 1 and you no longer have to? This is specification language? Give me a break. > In the real world we accept that it is > reasonable to place accessibility burdens on public accomodations, > such as places of business, sidewalks, or public broadcasts, but not > on private individuals. Please stop talking "down" to me, I am not an idiot - I am all too aware of the responsibilities of entities vs. individuals in regards to their duty to accommodate - probably more so than you given my decade long involvement in this field. None of the /technical/ reasons provided to date are good enough justification for making the @alt attribute optional - they only justify avoiding adding textual information to the image in question. Authoring tools should *always* present a means to add this information, and if the value is not supplied than that outcome rests with the content author - why this would affect a requirement of a technical specification is beyond me. There are many many rules that are abused, which should not be justification for omitting the rules. Client side scripting can be "abused" by authors to the point of destructiveness: should we then roll back the clock and remove the ability to provide client side scripting? > That is the legal and moral standard that most > accept. The remaining question, then, is what to do when a user does > not provide such information, and how the spec can best encourage > whatever is the best practice in this situation. By closing a loophole that can be exploited. Perhaps by determining a value or other means to indicate that the content author chose not to provide textual information, rather than just not even attempting. It has been argued that implies that there is no text value available, but that is not true: there may very well be text alternative available that either was consciously not provided, or that an authoring tool did not allow to be provided (current Flickr interface for example). There may in fact be *many* reasons why a content author can not, did not, and/or will not provide a value for @alt. None of these reasons however should be justification for *not* providing this information, and more importantly, none of these reasons are based in a /technical/ ability to do so, they are all author conscious decisions. Why user choice in this scenario should govern the technical spec, yet in the client side scripting scenario not, has not been explained or justified. Is it because malicious JavaScript can still be authored to be compliant? > > Number of people complaining does not affect the truth or falsehood of > a proposition. The very same statement can be applied to the claim that alt="" can harm accessibility. You are rehashing old business Maciej - move forward or move on. > > I personally prefer the noalt attribute, although it technically > "leaves out the alt". I think it has a small advantage (harder to > accidentally forget to indicate anything about the status of the > image), but also some disadvantages. Which choice is best should be > decided on technical merits, not whether the three letters A-L-T > appear in that order, as if that were some sort of magical talisman > automatically granting accessibility. Then let me be extremely clear here: an image without a textual alternative is incomplete to many users. How you provide this is secondary to the fact that it must be provided. Allowing an image to exist, to be conformant, when it is incomplete is wrong. Writing a specification that allows, neigh forgives, this situation is also wrong, and further has not been /technically/ proven to be a good idea. To date, @alt has been the method that has allowed content authors to directly link this information to the image. If you have a better way which does not involve the letters A-L-or T than by all means speak up. If noalt is the way forward, then put forth the pros and cons and let's talk about that - if it emerges as the better way forward then let's add it to the specification and close this debate. If reserved values is the way forward, then debate the pros and cons there and once again seek closure. The accessibility community however has been pretty consistent in their response to date: alone should not be considered conformant - full stop. > >> Once the WG comes to the conclusion that optional @alt as proposed >> is a >> non-starter and starts really discussing a different approach, this >> debate will continue to churn and go round-and-round 'till the cows >> come home. There have been many off-line comments within the working >> group about "dogma" emerging from the accessibility camp, but the >> responses from the other side are equally immobile and dogmatic - >> simply stating that will improve accessibility will not >> make it true, no matter how many times you say it. > > Ironically, a number of proposals other than simply omitting alt have > been made, including by the Editor, and they have been completely > ignored by the accessibility camp, as far as I can tell. Really? As an avid follower of *all* of the postings to both the public-html and wai-xtech mailing lists (two official means to discuss this topic) I have not heard a peep from Ian. If these proposals have surfaced in your back-room IRC channel or on the what-wg mailing list than I'm sorry, I read neither as they are outside of the official W3C process. I *am* aware of a number of alternative proposals on the W3C wiki [http://esw.w3.org/topic/HTML/IssueAltAttribute#head-27468e7ee9afd1f9e07186c 8d74f0b0168b3975a], and have in fact requested adding at least 2 entries to the list (suggestions by others), including one that *did* provide a scenario that could exist with an optional @alt ("...required except when the element is a child of x...") - not that I agree to it entirely but I do leave open the possibility, unlike some of you who insist that the only way forward is with an optional @alt. There are also 2 separate alternative ideas there that I suggested in earlier emails, and they have been quoted almost directly from those emails: * "Reserved value for alt like alt="_none"..." * "Explicitly note and provide as many other ways of providing alt text as possible..." Other accessibility advocates have also proposed alternative solutions, including Steven Faulkner and Leif Halvard Silli; again noted in the wiki above. What constructive ideas have *you* contributed towards a better solution? JF From rob at robburns.com Tue May 27 15:44:44 2008 From: rob at robburns.com (Robert J Burns) Date: Tue, 27 May 2008 22:44:44 +0000 Subject: [html4all] Is Flickr an Edge Case? (was Re: HTML Action Item 54) In-Reply-To: <20080527005935.GA30490@pickering.dbaron.org> References: <008501c8bf8f$0052bcf0$6d01a8c0@stanford.edu> <20080527005935.GA30490@pickering.dbaron.org> Message-ID: HI David, I'd like to say that I agree with everything you say here in this well- written and concise email. I think the intended audience for a document is very important. However, to me this suggest we need to augment the replaced elements with additional facilities and not simply drop the alt attribute in the case of photographs. Instead we should make use of the role attribute[1] to indicate whether the media is decorative or not and also add facilities to access descriptions of photographs (both subject descriptions and visual descriptions)[2]. Only when the role attribute has a proper value can authors then omit the alt attribute. This has the benefits of allowing the omission of the alt attribute in places where it may be unavoidable, yet still raising awareness among authors about the importance of these issues. Take care, Rob [1]: [2]: On May 27, 2008, at 12:59 AM, L. David Baron wrote: > > On Monday 2008-05-26 17:17 -0700, John Foliot wrote: >> Given that "photo sharing" is one of the most popular activities on >> the >> internet, all the more reason to not leave open the door that >> suggests that >> sometimes an image without @alt is "conformant". The constant >> refrain from >> the working group is that this would be a rare instance, yet you >> now suggest >> that it will be the majority, and not a rare instance at all. If >> 10 of the >> top 100 websites on the WWW have this magic get-out-of-jail-free >> card then >> surely others will seek to claim the same status. The precedent >> being >> suggested here is staggering. This is supposed to "help" >> accessibility? > > I'd like to step back into the real (non-Web) world for a pair of > brief examples: > > 1) A television news broadcast, expected to have an audience of > thousands or millions, is required to have closed captioning, > since that captioning will benefit a significant number of people > in the audience. The benefit of the captioning is greater than > the cost of doing it. > > 2) When I have a phone conversation with a friend, closed > captioning is not required. Neither of us would benefit from the > closed captioning. (If we wanted a written conversation, we'd use > email or IM.) There is zero benefit to the captioning, and it > would have significant cost (compared to that benefit), so it is > not done. > > One of the great things about the Web today is that it is blurring > the distinction between these two examples. Today's Web is not only > about large corporations publishing content for the masses to > consume. It's also about creation of content by individuals, a few > of whom have an opportunity to be heard widely that they never had > before, but many of whom are still essentially having conversations > among a small group of friends. > > Applying all the requirements we apply to mass media to content > creation for small audiences doesn't make sense. We have to > consider the costs and benefits of meeting these requirements. If > we enforce them on everyone, one thing we'll do is force a lot of > this content off of the Web entirely, which would make it accessible > to much fewer people. > > I think flickr is a great example of the read-write Web because it > contains a small number of very popular photos, and lots of photos > that have been viewed fewer than a dozen times. > > -David > > -- > L. David Baron http://dbaron.org/ > Mozilla Corporation http://www.mozilla.com/ > From foliot at wats.ca Tue May 27 17:05:06 2008 From: foliot at wats.ca (John Foliot) Date: Tue, 27 May 2008 17:05:06 -0700 Subject: [html4all] Is Flickr an Edge Case? (was Re: HTML Action Item 54) In-Reply-To: <20080527205909.GA20686@pickering.dbaron.org> Message-ID: <012301c8c056$7d03ca60$6d01a8c0@stanford.edu> L. David Baron wrote: > > So you're saying that you prefer people litter their meaningful > images with alt="" so that it's harder to distingush the meaningful > ones without useful alternate text from those that are purely > decorative? No, I have not said that, and have never said that. What I am saying is that the specification should not be written to remove the need for alternative text at *THE SPECIFICATION LEVEL*. That some users will abuse this goes without question, and a method to reduce the abuse should also be discussed. However an image without *any* means of directly attaching meaningful textual content should not be considered conformant at the technical level - full stop. It may still "work" in visual browsers, but it should not be deemed conformant, just as Google pages "work" but are not conformant to current HTML/XHTML specifications, due to the lack of a DTD. If you have been following this larger discussion at all you would also know that in fact I have even mused aloud about the possibility of relaxing the absolute mandate for @alt *SO LONG* as an alternative to @alt is in place. [http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/0393.html] I am less concerned about methodology than I am with results, and making @alt optional in "rare" circumstances (like on ten of the top 100 websites out there) flies in the face of a reasonable solution - it is a non-solution that simply solves (absolves?) the problem for one group of people without addressing the real needs of another group of people, despite protestations to the contrary. > > Would you agree that something like alt="[PHOTO]" or alt="[IMAGE]" > would be better for users in that case than alt=""? Yes, although perhaps not exactly like that. I had proposed the idea of some reserved values back in October 2007, each starting with an underscore (alt="_decorative", alt="_none", etc.) that could be used in scenarios where, as in the photo upload instance, it is problematic (not impossible, but problematic) to provide meaningful @alt to a large volume of images. It does not totally solve the problem, but it *does* ensure that @alt remains as a requirement for conformant HTML 5. [http://lists.w3.org/Archives/Public/public-html/2007Oct/0080.html] I personally am open to exploring any number of alternatives beyond the currently proposed "nothing" that an optional @alt affords. [W3C wiki: http://tinyurl.com/2v9c6f] > > If so, would you agree that it's worth standardizing what should be > used to mark such a case rather than having authors pick "[IMAGE]" or > "[PHOTO]" or their own variant? Yes. Would you agree that [] is useless? Would you further agree that: ... Is also useless, because that in effect is what you get when you have no @alt or equivalent. There is no disagreement that there is currently a problem - it is the proposed non-solution that is under debate. We can and must do better than what is currently proposed. JF From foliot at wats.ca Tue May 27 17:05:19 2008 From: foliot at wats.ca (John Foliot) Date: Tue, 27 May 2008 17:05:19 -0700 Subject: [html4all] Is Flickr an Edge Case? (was Re: HTML Action Item 54) In-Reply-To: <483C979B.2070101@andrewsidwell.co.uk> Message-ID: <012401c8c056$849aff50$6d01a8c0@stanford.edu> Andrew Sidwell wrote: > John Foliot wrote: >> Really? As an avid follower of *all* of the postings to both the >> public-html and wai-xtech mailing lists (two official means to >> discuss >> this >> topic) I have not heard a peep from Ian. If these proposals have >> surfaced in your back-room IRC channel or on the what-wg mailing >> list than I'm sorry, I read neither as they are outside of the >> official W3C process. > > Please see > http://lists.w3.org/Archives/Public/public-html/2008May/0073.html for > ths post in question. > I stand corrected and apologize for not remembering this post. Ian's suggestion certainly seems reasonable, and far superior to an optional @alt. I note from his example that the text equivalent is the text inside of the element - is it reasonable to presume then that:

Photo
Would be non-conformant, as there is no longer any text directly associated with the image in question? I suppose that a fair bit of useful data is already being transmitted simply by the fact that the image is identified as a photo* and that it is important, and so I guess it /could/ be considered complete, although less than useful. Is introducing a new attribute [importantimage] better than sticking with existing attributes and simply introducing new, reserved values? From an implementation perspective, which is easier to add to future user-agents? (* Photo. What if, instead it is an illustration, or a chart, or some other form of iconic or visual marker? Would a collection of reserved values be appropriate here?) JF From lachlan.hunt at lachy.id.au Tue May 27 17:42:38 2008 From: lachlan.hunt at lachy.id.au (Lachlan Hunt) Date: Wed, 28 May 2008 02:42:38 +0200 Subject: [html4all] Is Flickr an Edge Case? (was Re: HTML Action Item 54) In-Reply-To: <55687cf80805270230u2e8742e1id51cb4df70573915@mail.gmail.com> References: <008501c8bf8f$0052bcf0$6d01a8c0@stanford.edu> <55687cf80805270230u2e8742e1id51cb4df70573915@mail.gmail.com> Message-ID: <483CAA7E.70505@lachy.id.au> Steven Faulkner wrote: > I have noted the mention of a proposal by the editor, but have not > been able to find it, a pointer would be useful. See this proposal for the importantimage attribute. http://lists.w3.org/Archives/Public/public-html/2008May/0073.html -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/ From laura.lee.carlson at gmail.com Thu May 29 06:53:54 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Thu, 29 May 2008 08:53:54 -0500 Subject: [html4all] Mozilla is funding Ben Millard for an accessibility-related HTML5 study Message-ID: <1c8dbcaa0805290653y44fc252elc74a80defb5d1d15@mail.gmail.com> "The Mozilla Foundation is funding Ben Millard for an accessibility-related project to study how authors use HTML in practice, compare this with the semantics and accessibilty-related features in HTML5, identify any gaps, and help develop realistic ways to fill them." http://blog.hecker.org/2008/05/28/mozilla-foundation-activities-week-ending-20080523/ -- Laura L. Carlson From rob at robburns.com Thu May 29 09:41:26 2008 From: rob at robburns.com (Robert J Burns) Date: Thu, 29 May 2008 16:41:26 +0000 Subject: [html4all] complaining about too much implementation complexity for a proposal requiring zero implementation Message-ID: <16B4A745-64AC-4BE5-9F7E-E81DA40DACD6@robburns.com> Hello 4all, To highlight the insanity of the WhatWG, I just thought I'd draw your attention to this recent post from Andrew Sidwell[1]. In it he claims that my proposal to add 'marks' to the quotation elements adds too much implementation complexity when that particular proposal requires no implementation whatsoever. I really have to wonder what motivates someone to be so contrarian? Take care, Rob [1]: From rob at robburns.com Thu May 29 15:00:06 2008 From: rob at robburns.com (Robert J Burns) Date: Thu, 29 May 2008 22:00:06 +0000 Subject: [html4all] universal id attribute support Message-ID: <3317626D-A2CB-41B4-9BFA-7BF452630647@robburns.com> Hello 4all, Phillip and I were discussing one of the recent issues Gregory introduced and we got on the topic of the universal id attribute and the old way of using an empty anchor element with the name attribute (which apparently even recent versions of DreamWeaver sill do). Does anyone in this group know off the top of your head (or with quick reference) how far back we have to go to find browsers that do not support the universal id attribute as an link IDREF target? Just curious. Take care, Rob From rob at robburns.com Thu May 29 14:28:11 2008 From: rob at robburns.com (Robert J Burns) Date: Thu, 29 May 2008 21:28:11 +0000 Subject: [html4all] complaining about too much implementation complexity for a proposal requiring zero implementation Message-ID: Someone pointed out that I included the wrong URL showing Andrew?s bizarre response[2]. Looking at this again, I have to wonder whether something is going on here since someone claiming too much interoperability complexity in this situation, either doesn't understand implementations or is simply here to disrupt. [2]: original message: Hello 4all, To highlight the insanity of the WhatWG, I just thought I'd draw your attention to this recent post from Andrew Sidwell[1]. In it he claims that my proposal to add 'marks' to the quotation elements adds too much implementation complexity when that particular proposal requires no implementation whatsoever. I really have to wonder what motivates someone to be so contrarian? Take care, Rob [1]: From rob at robburns.com Thu May 29 15:57:06 2008 From: rob at robburns.com (Robert J Burns) Date: Thu, 29 May 2008 22:57:06 +0000 Subject: [html4all] complaining about too much implementation complexity for a proposal requiring zero implementation In-Reply-To: References: Message-ID: <2DFC3665-221B-4353-98E1-DD881EE71B09@robburns.com> quick correction for my last message: the phrase "interoperability complexity" should read "implementation complexity" which is what Andrew was claiming. Take care, Rob On May 29, 2008, at 9:28 PM, Robert J Burns wrote: > Someone pointed out that I included the wrong URL showing Andrew?s > bizarre response[2]. Looking at this again, I have to wonder whether > something is going on here since someone claiming too much > interoperability complexity in this situation, either doesn't > understand implementations or is simply here to disrupt. > > > [2]: > > > > original message: > Hello 4all, > > To highlight the insanity of the WhatWG, I just thought I'd draw your > attention to this recent post from Andrew Sidwell[1]. In it he claims > that my proposal to add 'marks' to the quotation elements adds too > much implementation complexity when that particular proposal requires > no implementation whatsoever. I really have to wonder what motivates > someone to be so contrarian? > > Take care, > Rob > > [1]: > > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki