Re: [whatwg] How not to fix HTML
Hi, From: Lachlan Hunt <[EMAIL PROTECTED]> I believe the issue is with the way screen readers handle existing forms. The problem is that each radio button or checkbox has it's own label, but the whole group is often associated with a single question and there is no way mark that up. e.g. Gender: Male Female In this case, when screen readers are in forms mode and the user is tabbing between form controls, it will only read out "Male" and "Female", it won't read out "Gender:". In this specific case, that's probably not a major issue because male and female are fairly self explanitory, but there are many cases where it's not. There are workarounds using fieldset and legend for the question, like this. Gender: Male Female I thought this was exactly what fieldset was designed to do. Group related form controls. Why do you consider it a workaround? Because of the way screen readers work, they now read out "Gender: Male" and "Gender: Female" as they tab to each control. This example demonstrates this technique. http://www.alistapart.com/d/prettyaccessibleforms/example_3/ The problem with that technique is that, because of the way legends are rendered in browsers, styling is somewhat restricted. I'd propose fixing the styling issues instead of changing the markup. Alternatively screen readers could be made smarter, also without changing the markup. Consider: Gender: male female Now the screen reader finds a group of radio buttons not in a fieldset. Radio buttons almost always have a question assigned to them. So go up a level in the tree (to the P) and get its child text nodes or .textContent or something, and use that as the "legend" for the radio group. (I'm not saying this algorithm is fool-proof, just saying that we don't necessarily need to change the markup to solve this issue.) Regards, Simon Pieters _ Eragon på vita duken 15/12! http://www.msn.se/noje/eragon/
Re: [whatwg] How not to fix HTML
Lachlan Hunt wrote: Ian Hickson wrote: Joe Clark wrote: http://blog.fawny.org/2006/10/28/tbl-html/ FYI, my response to that his here. http://lachy.id.au/log/2006/10/fixing-html Joe Clark has responed. http://lachy.id.au/log/2006/10/fixing-html#comment-713 His comment is copied here for discussion. annotation: A lot of things are annotations in PDF, including comments. We could use annotation for suprasegmental features like very long tooltips with block-level content, whose appearance could be user-controlled (and accessible by screen readers and keyboard). We could also just call blog comments annotations. part, section and article (some in “HTML5”): A part can be a chapter (we could also just say “chapter”). Articles could be included in sections that are in turn included in parts and served as pages. caption generically applicable to tables and figures: We can call it legend if you’d like. bibliographies, tables of contents, and indices (some in “HTML5”): “For tables of contents, isn’t existing list markup good enough?” No, I’d prefer stronger associations between ToC and item than just a hyperlink. I would also like to be able to suppress display of ToC in some presentations. Of course I can do that with divs. nonstruct for generic groupings: We can use it to group noncontiguous elements, useful in e.g. error reports on submitted forms or Ajax applications. E.g., nonstruct group=”X”. Error reports are a good use case, but I'm not sure that nonstruct would be best for them. There are accessibility reasons for explicitly marking up error information, particularly for forms, and current accessible techniques include writing the error message within the and/or fieldset's to force screen readers to read it out. Some markup for errors and a way to associate that error with a control might be useful. formula: “But doesn’t that fit into the category of science and mathematics that you had issues with earlier?” Yes, but this one we *need*. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] How not to fix HTML
Matthew Raymond wrote: The element gives the label for the group. That's similar to the idea I posted. True, but it eliminates the need for an |info| attribute on every element. Oops. Those info attributes were a copy and paste error. They should have been removed from #1 and #2, cause I wrote #3 first and copied that for the rest. The group attribute in my examples was referring to the name attribute, like the for attribute in yours. A better solution would be to use , where the value of |group| is the value of the controls' |name| attributes and not the value of |info| attributes, thus eliminating the need for |info|. Assuming you meant , that's exactly what I intended in my examples. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] How not to fix HTML
Lachlan Hunt wrote: > Matthew Raymond wrote: >>Here's a thought: >> >> | >> | Gender: >> |Male >> |Female >> | >> >>The element gives the label for the group. > > That's similar to the idea I posted. True, but it eliminates the need for an |info| attribute on every element. When you get into the dozens of radio buttons, you don't want to have to add an attribute to every element. You want to be able to just add the element for the group label. >> The |for| attribute in this case takes a name rather than and ID, > > I think that could be somewhat confusing using the same attribute name > for different, but somewhat related, features. That's why I like the > group attribute, because then there's no chance for confusion about > whether it takes a name or id in this context. Yeah, that bugged me a little too. A better solution would be to use , where the value of |group| is the value of the controls' |name| attributes and not the value of |info| attributes, thus eliminating the need for |info|. Example: | | Gender: | | | | Male | | | | | Female | | > Also, already supported, so there's fewer backwards > compatibility issues. I somewhat agree, but the standard presentation for an unassociated is typically just to treat it as a . It does, however, make it easier to style on browsers that don't allow styling on unknown elements, so you have a point in that regard.
Re: [whatwg] How not to fix HTML
Matthew Raymond wrote: Here's a thought: | | Gender: |Male |Female | The element gives the label for the group. That's similar to the idea I posted. The |for| attribute in this case takes a name rather than and ID, I think that could be somewhat confusing using the same attribute name for different, but somewhat related, features. That's why I like the group attribute, because then there's no chance for confusion about whether it takes a name or id in this context. Also, already supported, so there's fewer backwards compatibility issues. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] How not to fix HTML
Lachlan Hunt wrote: > I believe the issue is with the way screen readers handle existing > forms. The problem is that each radio button or checkbox has it's own > label, but the whole group is often associated with a single question > and there is no way mark that up. > > e.g. > > Gender: > > Male > > Female > Here's a thought: | | Gender: |Male |Female | The element gives the label for the group. The |for| attribute in this case takes a name rather than and ID, therefore it labels as a group control elements that have |name="gender"| as an attribute. It introduces only one element and one attribute for an unlimited amount of control elements.
Re: [whatwg] How not to fix HTML
Charles Iliya Krempeaux wrote: http://lachy.id.au/log/2006/10/fixing-html That link doesn't work. (I get a 404.) Fixed, thanks. There seems to ge a bug WordPress that causes posts to get marked as private for some unknown reason. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] How not to fix HTML
On Tue, 31 Oct 2006 03:01:47 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote:
>> Embed doesn't provide a fallback mechanism, and mixing parameters to the
>> plugin, and attributes can be error prone, depending on the plugin,
>> while object makes use of param.
> Sure but, everyone uses , and doesn't (in practice) work
> that well really. Also, is overloaded to do things like IFrames,
> and images, and plugins... having just for plugins would make it
> like and , the simple for plugins.
I belive that there should not be any special markup for plugins. The fact that
the browser uses a plugin to display the movie, or image, or VR scene, or
whatnot, is that browser's implementation detail. Some text-only browsers use
external programs to display images, but there isn't a special markup which
tells them to do so. I don't see why video clips should be any different.
Because one of the goals of WHAT, as I perceive it, is to provide semantic
markup for things that are currently marked up presentationally, I think that
HTML 5 should encourage transition from the presentational EMBED ("plugin
content") to the semantic OBJECT ("external subdocument") or even to more
semantically fine-grained VIDEO, AUDIO etc. It doesn't mean that support for
EMBED should be dropped: just like with FONT, there are many existing documents
which use it, and there probably will be authors which continue using it
despite its use being discouraged.
--
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] How not to fix HTML
Hello Lachlan,On 10/30/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote: Ian Hickson wrote:> Joe Clark wrote:>> http://blog.fawny.org/2006/10/28/tbl-html/FYI, my response to that his here. http://lachy.id.au/log/2006/10/fixing-htmlThat link doesn't work. (I get a 404.)See ya-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/
Re: [whatwg] How not to fix HTML
Ian Hickson wrote: Joe Clark wrote: http://blog.fawny.org/2006/10/28/tbl-html/ FYI, my response to that his here. http://lachy.id.au/log/2006/10/fixing-html * Allow multiple uses of the same id/label in a form and suddenly it becomes possible to mark up multiple-choice questionnaires accessibly. Could you elaborate on this? I'm not sure how this would work with the DOM, but I'm sure there's a way of addressing the use case you have in mind. I believe the issue is with the way screen readers handle existing forms. The problem is that each radio button or checkbox has it's own label, but the whole group is often associated with a single question and there is no way mark that up. e.g. Gender: Male Female In this case, when screen readers are in forms mode and the user is tabbing between form controls, it will only read out "Male" and "Female", it won't read out "Gender:". In this specific case, that's probably not a major issue because male and female are fairly self explanitory, but there are many cases where it's not. There are workarounds using fieldset and legend for the question, like this. Gender: Male Female Because of the way screen readers work, they now read out "Gender: Male" and "Gender: Female" as they tab to each control. This example demonstrates this technique. http://www.alistapart.com/d/prettyaccessibleforms/example_3/ The problem with that technique is that, because of the way legends are rendered in browsers, styling is somewhat restricted. There are a few possible ways to address this that I have thought of. 1. Allow labels to be associated with a group of form controls by referring to the control name. Gender: Male Female (I know the for attributes aren't technically required here, but due to current screen reader limitations, they are) 2. Allow labels to be associated with multiple controls, using a space separated list of IDREFs (like the headers attribute in tables). Gender: Male Female 3. Allow form controls to refer to additional labels. Gender: Male Female 4. Same as #3, but allow the link from the label elements instead. Gender: Male Female I think #1 is the best of these options because it's more convenient to type a single name, than multiple IDs. Plus, if a new control gets added to the group, it's implicitly associated without having to update the for attribute with the new ID. I don't particularly like #3 and #4, but they were my first thoughts, so I listed them anyway. Start a Working Group For Web Accessibility, independent from the W3C, and write an alternative to WCAG2. In about 2 years, if the work you've done starts getting more traction than the W3C's work, then you'll get their attention and then they'll start fixing the WCAG work. Joe has already decided to take a similar approach with his WCAG Samurai. However, he's keeping it top secret. There's virtually no information about it and no way to participate or even keep track of the work without an invitation. http://alistapart.com/articles/tohellwithwcag2/#WCAG-documents:WCAGSamurai http://wcagsamurai.org/ -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] How not to fix HTML
Joe Clark wrote: > http://blog.fawny.org/2006/10/28/tbl-html/ > > This is a classic problem in HTML development: The people doing the work > are geeks with computer-science interests who do not understand, for > example, newspapers, or screenplays, or, really, print publishing in > general. In some obscure way, they disdain print publishing, as the Web > is not print. Indeed it isn't, but print has structures the Web doesn't, > and it doesn't have them because people like these refuse to acknowledge > they exist or simply refuse to consider them. In the development of CSS, I actually think we erred on the side of traditional print-based documents rather than paying attention to computer science problems. For example, the existence of :first-line (which is a classic print-oriented feature) complicated the otherwise simple CSS1. CSS ignored, on the other hand, the interaction with programming languages (JavaScript) for too long. I think the CSS DOM would have been simpler if addressed in CSS2. Speaking for myself, I'm a print guy at heart. I publish newspapers [1], screenplays [2], novels [3] and specifications for print publishing in general [4][5]. All by way of HTML and CSS. [1] http://www.princexml.com/samples/ [2] http://people.opera.com/howcome/2006/ibsen [3] http://www.princexml.com/howcome/2006/slogans/slogans.pdf [4] http://www.w3.org/TR/css3-gcpm [5] http://www.w3.org/TR/css3-multicol -h&kon Håkon Wium Lie [EMAIL PROTECTED] http://people.opera.com/howcome [EMAIL PROTECTED] http://www.princexml.com/howcome
Re: [whatwg] How not to fix HTML
Hello,On 10/30/06, Ian Hickson <[EMAIL PROTECTED]> wrote: Hey Joe,Joe Clark wrote:> http://blog.fawny.org/2006/10/28/tbl-html/[...] > This is a classic problem in HTML development: The people doing the work> are geeks with computer-science interests who do not understand, for> example, newspapers, or screenplays, or, really, print publishing in > general. In some obscure way, they disdain print publishing, as the Web> is not print. Indeed it isn't, but print has structures the Web doesn't,> and it doesn't have them because people like these refuse to acknowledge > they exist or simply refuse to consider them.Note that while it certainly is true that I'm a geek who doesn'tunderstand many things outside my sphere of interests, it is _not_ truethat such concerns are being intentionally ignored here. I encourge you and anyone else who has desires for what HTML should do to speak up.Would you be open to hearing suggestions about how to add native video and video player support?(I have alot to say about that. And there's alot of people and companies who would find it very very useful. Rather than doing all the kludges that are in use today.) See ya-- Charles Iliya Krempeaux, B.Sc.charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/
Re: [whatwg] How not to fix HTML
On Mon, 30 Oct 2006, Joao Eiras wrote: > > > > > > Browsers will continue to suport embed, but the recomendations > > > shouldn't. > > > > Why not? > > Embed doesn't provide a fallback mechanism, and mixing parameters to the > plugin, and attributes can be error prone, depending on the plugin, > while object makes use of param. Sure but, everyone uses , and doesn't (in practice) work that well really. Also, is overloaded to do things like IFrames, and images, and plugins... having just for plugins would make it like and , the simple for plugins. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] How not to fix HTML
Na , Ian Hickson <[EMAIL PROTECTED]> escreveu: On Mon, 30 Oct 2006, Joao Eiras wrote: Ian Hickson <[EMAIL PROTECTED]> escreveu: > > * Make embed legal. Give it up, people: object doesn't work and never > > will. > HTML5 will make legal. Object works pretty fine. embed is duplicated functionality, not as flexible and accessible as object. Browsers will continue to suport embed, but the recomendations shouldn't. Why not? Embed doesn't provide a fallback mechanism, and mixing parameters to the plugin, and attributes can be error prone, depending on the plugin, while object makes use of param.
Re: [whatwg] How not to fix HTML
On Mon, 30 Oct 2006, Joao Eiras wrote: > > Ian Hickson <[EMAIL PROTECTED]> escreveu: > > > > * Make embed legal. Give it up, people: object doesn't work and never > > > will. > > HTML5 will make legal. > > Object works pretty fine. embed is duplicated functionality, not as flexible > and accessible as object. > Browsers will continue to suport embed, but the recomendations shouldn't. Why not? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] How not to fix HTML
Ian Hickson <[EMAIL PROTECTED]> escreveu: * Make embed legal. Give it up, people: object doesn't work and never will. HTML5 will make legal. Object works pretty fine. embed is duplicated functionality, not as flexible and accessible as object. Browsers will continue to suport embed, but the recomendations shouldn't.
Re: [whatwg] How not to fix HTML
Hey Joe, Joe Clark wrote: > http://blog.fawny.org/2006/10/28/tbl-html/ Note that in general I would encourage you to post your suggestions straight to the WHATWG list, as it is not guarenteed that I will always see your blog posts (though in this case, at least three separate systems and people alerted me to your post, so...). > If you are under the impression that I am lending de facto support to > WHAT WG, I'm not. Nor am I opposing WHAT WG. My concern is that WHAT WG > is doing exactly what the W3C did. Due in no small part to WHAT WG's > leadership by a strict standardista with an interest in video games, > "HTML5" replicates HTML's obsession with computer-science and math > elements. > > * HTML has samp, var, and kbd. I use all of them and I am pretty much > the only one who does. > * "HTML5" has meter (for measurements) and t for time notation. But, > true to member biases, "HTML5" bans the use of dl-dt/dd for dialogue, > a usage permitted by the HTML spec and in wide use by intelligent > developers like me who have to mark up documents unrelated to computer > science. (They'd prefer you use a thicket of blockquotes and cites. > And, presumably, nullify all the indention and italicization that > browsers will do by default.) Dialogue is an open issue. What the spec says about the matter today is certainly not the end of the discussion. Indeed there was recently a thread (which I will be getting to when I next look at list elements) about this very issue. (I'm starting to think that we may need a separate set of elements... maybe ... with and -- dialog talker and dialog... discourse? I dunno, whatever -- but the point is it would be backwards compatible with legacy UAs.) > This is a classic problem in HTML development: The people doing the work > are geeks with computer-science interests who do not understand, for > example, newspapers, or screenplays, or, really, print publishing in > general. In some obscure way, they disdain print publishing, as the Web > is not print. Indeed it isn't, but print has structures the Web doesn't, > and it doesn't have them because people like these refuse to acknowledge > they exist or simply refuse to consider them. Note that while it certainly is true that I'm a geek who doesn't understand many things outside my sphere of interests, it is _not_ true that such concerns are being intentionally ignored here. I encourge you and anyone else who has desires for what HTML should do to speak up. > This attitude - still present in WHAT WG, though it is separate and was > formed later - can be summed up as "Until we decide you are using our > computer-science tags adequately, we won't even consider the semantic > needs of your documents." I find the attitude ill-educated and > uncultured. It's Comic Book Guy deciding what will and won't be legal on > your own Web page. Again, that certainly isn't the intent. Please be vocal in your suggestions for HTML5. They will be taken into account in due course. We have already added elements for time, headers, footers, sections, navigation, and so forth, based especially on quantified author needs (some of the results of the studies made for these purposes were published on the code.google.com site). > We assuredly could use elements from tagged PDF like: > [...] > * annotation Could you elaborate on this? > * note and reference for footnotes, endnotes, and sidenotes (not aside > in "HTML5") Could you elaborate on this? Does the "title" attribute cover this case? What do you need that isn't covered by "title"? > * part, section and article (some in "HTML5") Could you elaborate on what isn't included? > * caption generically applicable to tables and figures This is something that will be considered (possibly relatively soon). > * bibliographies, tables of contents, and indices (some in "HTML5") Could you elaborate on what isn't covered here? > * nonstruct for generic groupings Could you elaborate on what it is that and don't cover here? > * formula Math in HTML5 is an area that is undergoing active research at the moment. > Why not just borrow those? Why give us a way to mark up measurements but > no way to mark up structural elements in layouts like footnotes and > deks? Because the people asking for gauges were vocal and gave solid use cases, while the people asking for deks were not. I have no idea what a "dek" is. If you could elaborate on your use cases, give examples, show Web pages that are working around the absence of an element for the purpose, etc, then that would be a huge help. As you said, I'm a geek, and I don't know about things outside my realms of interest. WHATWG is completely open; your input and the input of everyone else is not only accepted, it's desired. Please help us, tell us what you want, why you want it, how you get around the lack of it today. (Note: is actually a gauge UI
