Re: [whatwg] Context help in Web Forms
Adding HTML-WG so people know what's going on and can comment if necessary. On Wed, 22 Oct 2008 14:42:48 +0700, Ian Hickson [EMAIL PROTECTED] wrote: [in the context of a request for a way to identify context-specific help, e.g. some further information about a given form field that can be made available without requiring the user to read it]. ... I don't understand how inline text is inaccessible. Could you elaborate? An example would be useful. Large quantities of text reduce the overall accessibility of a page in a couple of ways. The most common is actually making the page harder to read - and reading difficulties are very common as a type of disability. The effect can be very mild (it is a bit slower) or very severe (many people actually find it incredibly difficult to read something if there is too much text there). (For this reason, designers will often look for ways not to have the text present in the page's default view...) The other common problem it introduces is reducing the ability of users to navigate efficiently. This applies especially to screen reader users who are scanning text by skipping through it. One of the benefits HTML provides over plain text is the various navgiable structures to improve this situation - having a lot of inline text can negate some of that improvement, especially if it is not marked in a way that makes it clear that it is ancillary to the main content. (One of the problems with visible metadata is that people assume that since it is visible it doesn't really need more markup...) Hixie had said... Great! Thanks. I think your idea of making rel=help be relative to the nearest parent label is a good one. We could also say it is relative to the nearest parent label, body, section, form, fieldset, or other such grouping element. I'll look at this in more detail when defining the rel= values. Chaals replied: Cool. The idea is that the thing is really reliably discoverable - otherwise authors will come up with something that makes sense but breaks the implicit model that the spec is built on. I am actually not sure that we mean the same thing when we say nearest but I will talk to you off the list about that to clarify that in my mind :-) Ok. rel=help is now defined to apply to the link element's parent and its children. Thanks, this seems sound to me. 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: http://www.opera.com
Re: [whatwg] Context help in Web Forms
On Sun, 12 Jun 2005, Charles McCathieNevile wrote: One of the difficulties is that many content providers don't want to clutter their page with help links Actually, given the way many sites actually do have help links, or ? icons, or the like, I don't see content providers being reluctant to do this, as you say. You are right that many sites *do* have help links present in the page. Some even try to have them on a per question basis. There is in fact an accessibility cost in this for some users (the huge difficulty with getting accessibility right is that it is a very heterogenous, and at times *apparently* conflicting set of user requirements). There are others who don't. The implementation of the contexthelp attribute was driven by the US Treasury, whose audience must measure in millions or tens of millions (I don't know how many US taxpayers read information online around April each year, when they have to file their returns, but I would guess it is a very large number indeed). They were unwilling to add all the visible links. There are many others who believe that all those extra links are clutter. I think you and I agree that in fact having them explicit and clearly discoverable is valuable. That doesn't change the fact that there are many designers who do look for a way to hide the help, while making it accessible to screen reader users, or similar. They tend to use CSS tricks at the moment, some of which defeat their goals quite neatly, others of which complicate sites endlessly, and some of which seem to work. I don't understand how inline text is inaccessible. Could you elaborate? An example would be useful. Great! Thanks. I think your idea of making rel=help be relative to the nearest parent label is a good one. We could also say it is relative to the nearest parent label, body, section, form, fieldset, or other such grouping element. I'll look at this in more detail when defining the rel= values. Cool. The idea is that the thing is really reliably discoverable - otherwise authors will come up with something that makes sense but breaks the implicit model that the spec is built on. I am actually not sure that we mean the same thing when we say nearest but I will talk to you off the list about that to clarify that in my mind :-) Ok. rel=help is now defined to apply to the link element's parent and its children. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Context help in Web Forms
A LINK element cannot have a LABEL ancestor so Ian's answer seems to answer a different request. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, October 22, 2008 9:43 AM To: Charles McCathieNevile Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Context help in Web Forms On Sun, 12 Jun 2005, Charles McCathieNevile wrote: Great! Thanks. I think your idea of making rel=help be relative to the nearest parent label is a good one. We could also say it is relative to the nearest parent label, body, section, form, fieldset, or other such grouping element. I'll look at this in more detail when defining the rel= values. Cool. The idea is that the thing is really reliably discoverable - otherwise authors will come up with something that makes sense but breaks the implicit model that the spec is built on. I am actually not sure that we mean the same thing when we say nearest but I will talk to you off the list about that to clarify that in my mind :-) Ok. rel=help is now defined to apply to the link element's parent and its children. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Context help in Web Forms
On Wed, 22 Oct 2008, Kristof Zelechovski wrote: rel=help is now defined to apply to the link element's parent and its children. A LINK element cannot have a LABEL ancestor so Ian's answer seems to answer a different request. By link element I meant whatever element was creating the link (in this case, a or area). Sorry about the confusion. The spec is clear about this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Context help in Web Forms
On Wed, 22 Oct 2008, Jonas Sicking wrote: Ian Hickson wrote: Great! Thanks. I think your idea of making rel=help be relative to the nearest parent label is a good one. We could also say it is relative to the nearest parent label, body, section, form, fieldset, or other such grouping element. I'll look at this in more detail when defining the rel= values. Cool. The idea is that the thing is really reliably discoverable - otherwise authors will come up with something that makes sense but breaks the implicit model that the spec is built on. I am actually not sure that we mean the same thing when we say nearest but I will talk to you off the list about that to clarify that in my mind :-) Ok. rel=help is now defined to apply to the link element's parent and its children. Would it make sense to say that if link rel=help appears in the head, that it appears to the whole page? It's said that for some time now. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Context help in Web Forms
Ian Hickson wrote: Great! Thanks. I think your idea of making rel=help be relative to the nearest parent label is a good one. We could also say it is relative to the nearest parent label, body, section, form, fieldset, or other such grouping element. I'll look at this in more detail when defining the rel= values. Cool. The idea is that the thing is really reliably discoverable - otherwise authors will come up with something that makes sense but breaks the implicit model that the spec is built on. I am actually not sure that we mean the same thing when we say nearest but I will talk to you off the list about that to clarify that in my mind :-) Ok. rel=help is now defined to apply to the link element's parent and its children. Would it make sense to say that if link rel=help appears in the head, that it appears to the whole page? / Jonas
Re: [whatwg] Context help in Web Forms
On Mon, 2 Jun 2008, Matthew Paul Thomas wrote: The disadvantage of using a data-* attribute is that more kinds of mistakes would be undetectable by a validator. It would have no idea that (a) the value of the attribute must be the ID of an element elsewhere in the document, and (b) each value must be unique within the document. I wonder if the data-* attribute naming scheme could be classified somehow to allow basic type checking like this. I expect there will be other cases where authors want an attribute value to match the ID of an element in the page. On Tue, 3 Jun 2008, Henri Sivonen wrote: I don't like the idea of trying to encode the datatypes of data-* attributes in a validator-sensitive way. What datatypes would a validator support for data-* attributes? The HTML5 datatype library used by Validator.nu already contains 41 datatypes, but people will likely want to have others. The whole point of data-* is to provide a place where a validator doesn't go without authors having to abuse e.g. title which is a freeform but exposed to humans. The foreseeable problem with data-* is, of course, that microformat-like activity will happen there instead of going through the trouble of getting unprefixed validator-sensitive attributes minted with community review in the WHATWG and the HTML WG. On Wed, 4 Jun 2008, Anne van Kesteren wrote: That'd be wrong as data-* does not allow implementation by UAs... Having said that, if we don't make it clear what the idea is that might end up happening in practice here and there. I agree that not constraining data-* will lead to a validation hole where people can't check that their data is matching their presumed schema, but I think the right solution to this is for validators to offer out-of-band ways to specify schemas for data-* attributes, not for the spec to constrain the values, IMHO. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Context help in Web Forms
On Mon, 02 Jun 2008 09:40:55 -0300, Matthew Paul Thomas [EMAIL PROTECTED] wrote: Ian Hickson wrote on 27/05/08 07:47: On Mon, 12 Nov 2007, Matthew Paul Thomas wrote: On Oct 30, 2007, at 6:01 PM, Ian Hickson wrote: On Mon, 13 Jun 2005, Matthew Thomas wrote: ... Many applications provide inline help which is not a label, and the same attributes would be appropriate here: div rel=help for=phone-numberpThe full number, including country code./p pExample: samp+61 3 1234 5678/samp/p/div How would UAs use this? UAs likely wouldn't, but scripts could. For example, a form might include sparing help by default, with a style sheet hiding more exhaustive help (as indicated by rel=help). Then a script could add a small help button after each control that has associated help (i.e. each control with name=x where there exists an element on the page with rel=help for=x). When a control's help button was clicked, the control's help would be shown. ... The data-* attributes are intended for scripts like this. ... The disadvantage of using a data-* attribute is that more kinds of mistakes would be undetectable by a validator. It would have no idea that (a) the value of the attribute must be the ID of an element elsewhere in the document, and (b) each value must be unique within the document. Indeed. There is an attribute for this called contexthelp or something that JAWS implemented years ago, collaborating with the US Treasury or seomthing. I proposed it to the whatwg a couple of years ago but my recollection is that this was rejected as not useful or important or something. Certainly it seems mor sensible to go with existing implementation than to make up something incompatible, and it seems that using data-* means we will actually get several dozen different versions of this - using ARIA would be an approximately infinitely better alternative. I wonder if the data-* attribute naming scheme could be classified somehow to allow basic type checking like this. I expect there will be other cases where authors want an attribute value to match the ID of an element in the page. Sounds like a semantic web project to me, infobot. (Personally I think that would be useful, but at that point I'd switch to basing my work on XML anyway, where there are infrastructures for this kind of thing). 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
Re: [whatwg] Context help in Web Forms
On Jun 2, 2008, at 15:40, Matthew Paul Thomas wrote: The disadvantage of using a data-* attribute is that more kinds of mistakes would be undetectable by a validator. It would have no idea that (a) the value of the attribute must be the ID of an element elsewhere in the document, and (b) each value must be unique within the document. I wonder if the data-* attribute naming scheme could be classified somehow to allow basic type checking like this. I expect there will be other cases where authors want an attribute value to match the ID of an element in the page. I don't like the idea of trying to encode the datatypes of data-* attributes in a validator-sensitive way. What datatypes would a validator support for data-* attributes? The HTML5 datatype library used by Validator.nu already contains 41 datatypes, but people will likely want to have others. The whole point of data-* is to provide a place where a validator doesn't go without authors having to abuse e.g. title which is a freeform but exposed to humans. The foreseeable problem with data-* is, of course, that microformat- like activity will happen there instead of going through the trouble of getting unprefixed validator-sensitive attributes minted with community review in the WHATWG and the HTML WG. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Context help in Web Forms
On Tue, 03 Jun 2008 20:51:39 +0200, Henri Sivonen [EMAIL PROTECTED] wrote: I don't like the idea of trying to encode the datatypes of data-* attributes in a validator-sensitive way. What datatypes would a validator support for data-* attributes? The HTML5 datatype library used by Validator.nu already contains 41 datatypes, but people will likely want to have others. The whole point of data-* is to provide a place where a validator doesn't go without authors having to abuse e.g. title which is a freeform but exposed to humans. I agree. The foreseeable problem with data-* is, of course, that microformat-like activity will happen there instead of going through the trouble of getting unprefixed validator-sensitive attributes minted with community review in the WHATWG and the HTML WG. That'd be wrong as data-* does not allow implementation by UAs... Having said that, if we don't make it clear what the idea is that might end up happening in practice here and there. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Context help in Web Forms
Ian Hickson wrote on 27/05/08 07:47: On Mon, 12 Nov 2007, Matthew Paul Thomas wrote: On Oct 30, 2007, at 6:01 PM, Ian Hickson wrote: On Mon, 13 Jun 2005, Matthew Thomas wrote: ... Many applications provide inline help which is not a label, and the same attributes would be appropriate here: div rel=help for=phone-numberpThe full number, including country code./p pExample: samp+61 3 1234 5678/samp/p/div How would UAs use this? UAs likely wouldn't, but scripts could. For example, a form might include sparing help by default, with a style sheet hiding more exhaustive help (as indicated by rel=help). Then a script could add a small help button after each control that has associated help (i.e. each control with name=x where there exists an element on the page with rel=help for=x). When a control's help button was clicked, the control's help would be shown. ... The data-* attributes are intended for scripts like this. ... The disadvantage of using a data-* attribute is that more kinds of mistakes would be undetectable by a validator. It would have no idea that (a) the value of the attribute must be the ID of an element elsewhere in the document, and (b) each value must be unique within the document. I wonder if the data-* attribute naming scheme could be classified somehow to allow basic type checking like this. I expect there will be other cases where authors want an attribute value to match the ID of an element in the page. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Context help in Web Forms
On Oct 30, 2007, at 6:01 PM, Ian Hickson wrote: ... On Mon, 13 Jun 2005, Matthew Thomas wrote: Or perhaps a ... rel=help for=phone-number, to be consistent with the for= attribute in label. This is a possibility, but is it really needed? In general it seems we'd want to encourage authors to put the links near the text and controls to which it applies. Sure, but I don't see how it's different from label in that respect: we want to encourage authors to put label near the control to which it applies, but label already has for=. (label can have weak semantic value even when not related to a particular control, but then so could rel=help.) Many applications provide inline help which is not a label, and the same attributes would be appropriate here: div rel=help for=phone-numberpThe full number, including country code./p pExample: samp+61 3 1234 5678/samp/p/div How would UAs use this? UAs likely wouldn't, but scripts could. For example, a form might include sparing help by default, with a style sheet hiding more exhaustive help (as indicated by rel=help). Then a script could add a small help button after each control that has associated help (i.e. each control with name=x where there exists an element on the page with rel=help for=x). When a control's help button was clicked, the control's help would be shown. Another possible presentation would be reserving whitespace to the right of the form, and making whatever rel=help for=x visible in that space whenever input name=x was focused. http://uxmatters.com/MT/archives/000191.php shows these and other examples of dynamic help. The cite= attribute was also mentioned in this thread as one that is practically useless because there is no good way of presenting it. (Sometimes authors use JavaScript to pull it out of a blockquote and present it as a link underneath. But that still has accessibility problems, because it doesn't work without JavaScript, and the resulting link text is either a raw URL or the same text for every quote. These problems make the technique even more unworkable for q.) As a result, authors usually use an a link to the resource they're quoting (look at most self-hosted Weblogs for examples), and there ends up being no machine-readable connection between the link and the quote. This could similarly be achieved in the a element with a for= attribute giving the ID of the blockquote or q element. Interesting idea. The majority of authors still wouldn't use these attributes, because it would give them no presentational benefit. But at least authors would be slightly more likely to use them than to use attributes that they have to re-present using extra elements or JavaScript. We should probably aim higher than that though... ... I'm suggesting either replacing foo cite=url/foo with bar rel=citation for=id-of-foo, or dropping cite= altogether. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Context help in Web Forms
On Sun, 12 Jun 2005, Derek Featherstone wrote: Anyway, having the ability to add a help link in the body, with particular context-sensitivity (as discussed for including a link with rel=help in a form control label) is probably sufficient. I'll take that discussion back to W3C's Protocols and Formats group (the part of WAI that deals with review of specifications to ensure they enable accessibility) and see what they think... Great! Thanks. I think your idea of making rel=help be relative to the nearest parent label is a good one. We could also say it is relative to the nearest parent label, body, section, form, fieldset, or other such grouping element. I'll look at this in more detail when defining the rel= values. The spec makes it relative to the parent of the a element. I've actually been thinking about that for a while - rather than leaving it to a guess why not bind it specifically with something like an about attribute that identifies the specific element/node it references? rel=help about=#phone-number That would allow for much more flexibility and robustness wouldn't it? On Mon, 13 Jun 2005, Matthew Thomas wrote: Or perhaps a ... rel=help for=phone-number, to be consistent with the for= attribute in label. This is a possibility, but is it really needed? In general it seems we'd want to encourage authors to put the links near the text and controls to which it applies. Many applications provide inline help which is not a label, and the same attributes would be appropriate here: div rel=help for=phone-numberpThe full number, including country code./p pExample: samp+61 3 1234 5678/samp/p/div How would UAs use this? The cite= attribute was also mentioned in this thread as one that is practically useless because there is no good way of presenting it. (Sometimes authors use JavaScript to pull it out of a blockquote and present it as a link underneath. But that still has accessibility problems, because it doesn't work without JavaScript, and the resulting link text is either a raw URL or the same text for every quote. These problems make the technique even more unworkable for q.) As a result, authors usually use an a link to the resource they're quoting (look at most self-hosted Weblogs for examples), and there ends up being no machine-readable connection between the link and the quote. This could similarly be achieved in the a element with a for= attribute giving the ID of the blockquote or q element. Interesting idea. The majority of authors still wouldn't use these attributes, because it would give them no presentational benefit. But at least authors would be slightly more likely to use them than to use attributes that they have to re-present using extra elements or JavaScript. We should probably aim higher than that though... -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Context help in Web Forms
On Sat, 11 Jun 2005, Charles McCathieNevile wrote: Sorry, I should have been clearer. We got feedback from implementors saying they couldn't think of a way to make it discoverable, and we got feedback from Web descigners saying it wouldn't be useful if it wasn't discoverable. OK. This is in fact a generic problem in HTML - consider most of the things that the userJS http://userjs.org/scripts/browser/enhancements/frameset-links does - links like longdesc, the cite attribute from quotes, etc. Longdesc in particular is important to get right, for accessibility (I am thinking about this because I am blogging photos from a phone and want to share the results with friends who are blind). In fact longdesc is a perfect example of a feature that, due to lack of discoverability, became one of HTML's most thorough failures. To the point where the accessibility community encouraged authors to use explicit D-links rather than longdesc=. Indeed, longdesc= has been dropped from XHTML2 and (as soon as I get around to defining img, baring anyone giving good reasons not to do this) will be dropped in HTML5 as well. They are discoverable in the sense that they are in the DOM, which allows user agents to work out something sensible - context menu (like iCab does for most of these things) or a transformation on demand that shows the links like Tarquin's script or an XSLT as an alternate stylesheet, or exposing them in a particular user interface like JAWS does with its propretary contexthelp attribute. IMHO, longdesc is useless. About 3 people on the planet use it. Sure, theoretically it could be useful, but in practice since it is not shown by user agents (and since there is no good way really to show it in user agents that would be discovered by a majority of users) most authors just ignore it. And if authors ignore it, it won't be consistently available, and if it isn't consistently available, users won't use it when it _is_ available, since they won't expect it to work. One of the difficulties is that many content providers don't want to clutter their page with help links - something that I think is in fact a bad design decision on their part, but nevertheless is a reality. (This is related to the problems of design limitations that lead to things like image replacement techniques...) Actually, given the way many sites actually do have help links, or ? icons, or the like, I don't see content providers being reluctant to do this, as you say. Giving them a way to use their already-present and discoverable help links and mark them up so that UAs can do with them something useful is the way most likely to increase the availablility of UA-detectable help. Anyway, having the ability to add a help link in the body, with particular context-sensitivity (as discussed for including a link with rel=help in a form control label) is probably sufficient. I'll take that discussion back to W3C's Protocols and Formats group (the part of WAI that deals with review of specifications to ensure they enable accessibility) and see what they think... Great! Thanks. I think your idea of making rel=help be relative to the nearest parent label is a good one. We could also say it is relative to the nearest parent label, body, section, form, fieldset, or other such grouping element. I'll look at this in more detail when defining the rel= values. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Context help in Web Forms
On Sun, 12 Jun 2005 12:52:25 +0200, Ian Hickson [EMAIL PROTECTED] wrote: On Sat, 11 Jun 2005, Charles McCathieNevile wrote: In fact longdesc is a perfect example of a feature that, due to lack of discoverability, became one of HTML's most thorough failures. To the point where the accessibility community encouraged authors to use explicit D-links rather than longdesc=. No, this is a misreading of what we were saying. In the late 1990s there was no support for longdesc, so authors were encouraged to *also* use a redundant D-link. Indeed, longdesc= has been dropped from XHTML2 and (as soon as I get around to defining img, baring anyone giving good reasons not to do this) will be dropped in HTML5 as well. This will be reviewed. The object model is generally considered more useful. But it depends to some extent on the tools available - being able to recognise an image from a description is an important use case for a small group of people dealing with a small number of situations - many more than 3, but many fewer than everyone - since most people recognise the image by seeing it. IMHO, longdesc is useless. About 3 people on the planet use it. Sure, theoretically it could be useful, It is, in practice, useful. Unfortunately like many of the harder things in producing standards-compliant accessible content, there is indeed a poor track record of usage. but in practice since it is not shown by user agents (and since there is no good way really to show it in user agents that would be discovered by a majority of users) most authors just ignore it. And if authors ignore it, it won't be consistently available, and if it isn't consistently available, users won't use it when it _is_ available, since they won't expect it to work. The expectation of it working is based on whether the browser implements it. And so far, the failure has been on the browser side - there are extensions available for Firefox and Opera, and iCab implements it properly (but is a useless browser for the primary group who benefits due to assorted other issues). So it is more surprising that there are users for it even in the current state of browser development. Discoverability in this case doesn't seem to me a primary issue. It is a relatively small target audience, and the more generic aspects of its use are to do with machine-processing the web, where presence in reliably treatable code is sufficient discoverability. It isn't going to become massively prevalent any time soon, but this isn't the sole measure of effectiveness. As it happens the current Opera solution is to make the link clearly discoverable *for those who want it*. Firefox (via an extension) and iCab make it available in a context menu. There will be different solutions which are more appropriate for different users, and many users will never care about this at all. One of the difficulties is that many content providers don't want to clutter their page with help links Actually, given the way many sites actually do have help links, or ? icons, or the like, I don't see content providers being reluctant to do this, as you say. You are right that many sites *do* have help links present in the page. Some even try to have them on a per question basis. There is in fact an accessibility cost in this for some users (the huge difficulty with getting accessibility right is that it is a very heterogenous, and at times *apparently* conflicting set of user requirements). There are others who don't. The implementation of the contexthelp attribute was driven by the US Treasury, whose audience must measure in millions or tens of millions (I don't know how many US taxpayers read information online around April each year, when they have to file their returns, but I would guess it is a very large number indeed). They were unwilling to add all the visible links. There are many others who believe that all those extra links are clutter. I think you and I agree that in fact having them explicit and clearly discoverable is valuable. That doesn't change the fact that there are many designers who do look for a way to hide the help, while making it accessible to screen reader users, or similar. They tend to use CSS tricks at the moment, some of which defeat their goals quite neatly, others of which complicate sites endlessly, and some of which seem to work. Great! Thanks. I think your idea of making rel=help be relative to the nearest parent label is a good one. We could also say it is relative to the nearest parent label, body, section, form, fieldset, or other such grouping element. I'll look at this in more detail when defining the rel= values. Cool. The idea is that the thing is really reliably discoverable - otherwise authors will come up with something that makes sense but breaks the implicit model that the spec is built on. I am actually not sure that we mean the same
Re: [whatwg] Context help in Web Forms
Derek Featherstone wrote: ... I've actually been thinking about that for a while - rather than leaving it to a guess why not bind it specifically with something like an about attribute that identifies the specific element/node it references? rel=help about=#phone-number ... Or perhaps a ... rel=help for=phone-number, to be consistent with the for= attribute in label. Many applications provide inline help which is not a label, and the same attributes would be appropriate here: div rel=help for=phone-numberpThe full number, including country code./p pExample: samp+61 3 1234 5678/samp/p/div The cite= attribute was also mentioned in this thread as one that is practically useless because there is no good way of presenting it. (Sometimes authors use JavaScript to pull it out of a blockquote and present it as a link underneath. But that still has accessibility problems, because it doesn't work without JavaScript, and the resulting link text is either a raw URL or the same text for every quote. These problems make the technique even more unworkable for q.) As a result, authors usually use an a link to the resource they're quoting (look at most self-hosted Weblogs for examples), and there ends up being no machine-readable connection between the link and the quote. This could similarly be achieved in the a element with a for= attribute giving the ID of the blockquote or q element. The majority of authors still wouldn't use these attributes, because it would give them no presentational benefit. But at least authors would be slightly more likely to use them than to use attributes that they have to re-present using extra elements or JavaScript. -- Matthew Thomas http://mpt.net.nz/
Re: [whatwg] Context help in Web Forms
On Mon, 06 Jun 2005 12:07:16 +0200, Ian Hickson [EMAIL PROTECTED] wrote: On Sat, 28 May 2005, Charles McCathieNevile wrote: it would be helpful to have a way of including extra help, which may be provided by a popup dialogue, mouseover, etc. The HTML4 title attribute provides this. At one point we considered having a second attribute with a URI, help=, similar to the XForms equivalent, for more detailed context-sensitive help. However, we got feedback from implementors and Web designers saying it wouldn't be that useful since it was not discoverable, and so it was removed. Hang on, you mean the people who would implement the discovery mechanism said there won't be one, so they don't recommend it? I presume not, but that's how I keep reading this. Can you please clarify? In HTML5 it is likely that a rel= value for the a element will be introduced which could be used to provide context-sensitive help while still having discoverability for the common case: the link would be visible in the markup, and the UA would be able to determine the closest matching such link (according to a given algorithm) when looking for help. I guess you were thinking closest form control or something. Nearness seems in general like a really bad way to guess where the help is. Do you mean closest in the markup, or in the laid-out rendering? If the link were required to be inside a label in order to be associated with a form control, that might make sense though. cheers Chaals -- Charles McCathieNevile [EMAIL PROTECTED] hablo espaol - je parle franais - jeg lrer norsk Here's one we prepared earlier: http://www.opera.com/download
Re: [whatwg] Context help in Web Forms
On Sat, 11 Jun 2005, Charles McCathieNevile wrote: At one point we considered having a second attribute with a URI, help=, similar to the XForms equivalent, for more detailed context-sensitive help. However, we got feedback from implementors and Web designers saying it wouldn't be that useful since it was not discoverable, and so it was removed. Hang on, you mean the people who would implement the discovery mechanism said there won't be one, so they don't recommend it? I presume not, but that's how I keep reading this. Can you please clarify? Sorry, I should have been clearer. We got feedback from implementors saying they couldn't think of a way to make it discoverable, and we got feedback from Web descigners saying it wouldn't be useful if it wasn't discoverable. (Several suggestions were made as to how to make it discoverable, but none were considered good from a usability perspective.) In HTML5 it is likely that a rel= value for the a element will be introduced which could be used to provide context-sensitive help while still having discoverability for the common case: the link would be visible in the markup, and the UA would be able to determine the closest matching such link (according to a given algorithm) when looking for help. I guess you were thinking closest form control or something. I meant closest link, from the perspective of a form control. Nearness seems in general like a really bad way to guess where the help is. Do you mean closest in the markup, or in the laid-out rendering? If the link were required to be inside a label in order to be associated with a form control, that might make sense though. I have noted this for when rel=help is defined. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Context help in Web Forms
On Sat, 11 Jun 2005 16:46:58 +0200, Ian Hickson [EMAIL PROTECTED] wrote: On Sat, 11 Jun 2005, Charles McCathieNevile wrote: Sorry, I should have been clearer. We got feedback from implementors saying they couldn't think of a way to make it discoverable, and we got feedback from Web descigners saying it wouldn't be useful if it wasn't discoverable. OK. This is in fact a generic problem in HTML - consider most of the things that the userJS http://userjs.org/scripts/browser/enhancements/frameset-links does - links like longdesc, the cite attribute from quotes, etc. Longdesc in particular is important to get right, for accessibility (I am thinking about this because I am blogging photos from a phone and want to share the results with friends who are blind). They are discoverable in the sense that they are in the DOM, which allows user agents to work out something sensible - context menu (like iCab does for most of these things) or a transformation on demand that shows the links like Tarquin's script or an XSLT as an alternate stylesheet, or exposing them in a particular user interface like JAWS does with its propretary contexthelp attribute. One of the difficulties is that many content providers don't want to clutter their page with help links - something that I think is in fact a bad design decision on their part, but nevertheless is a reality. (This is related to the problems of design limitations that lead to things like image replacement techniques...) Anyway, having the ability to add a help link in the body, with particular context-sensitivity (as discussed for including a link with rel=help in a form control label) is probably sufficient. I'll take that discussion back to W3C's Protocols and Formats group (the part of WAI that deals with review of specifications to ensure they enable accessibility) and see what they think... cheers and thanks - I think this discussion has helped me clarify some of the issues too. Chaals -- Charles McCathieNevile [EMAIL PROTECTED] hablo espaol - je parle franais - jeg lrer norsk Here's one we prepared earlier: http://www.opera.com/download
