[WSG] browsers render differently with Optroup
I am working on a web form that has Optgroup in it, and the first time I realized browsers render this attribute differently. I have something like this: optgroup label=United States option label=CA value=CaliforniaCalifornia/option /optgroup In Firefox, it display: California In Safari and Opera, it displays: CA p/s. Haven't check on IE yet. According to w3c's html spec http://www.w3.org/TR/html4/interact/forms.html#form-labels I made an example page with markup copied from the above page http://lotusfromthemud.com/option.html represents the following grouping: None PortMaster 3 3.7.1 3.7 3.5 PortMaster 2 3.7 3.5 IRX 3.7R 3.5R In 17.6.1 Pre-selected options, scolled down to the end of 17.6.1, It says: A graphical user agent might render this as : (screenshot from old Netscape I think) Gecko based browsers are graphical user agents yet Safari and Opera are not? (!!!) Screen reader isn't graphic user agent, so it will read 'CA instead of 'California'? It's quite annoying if I have to add : option label=California value=CaliforniaCalifornia/option tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] browsers render differently with Optroup
On Oct 24, 2007, at 3:27 PM, Tee G. Peng wrote: I am working on a web form that has Optgroup in it, and the first time I realized browsers render this attribute differently. IE Mac displays 'CA' in your 1st example IE 7 Win displays 'CA' in your 1st example Opera 9.5 alpha: idem ditto. I made an example page with markup copied from the above page http://lotusfromthemud.com/option.html Under 17.6.1 it says (specifically for label in option): http://www.w3.org/TR/html401/interact/forms.html#adef-label-OPTION label = text [CS] This attribute allows authors to specify a shorter label for an option than the content of the OPTION element. When specified, user agents should use the value of this attribute rather than the content of the OPTION element as the option label. That sounds, to me, as validating what Safari, IE Mac, IE Win Camino are doing. Note that Firefox is not wrong by the description given above. Philippe --- Philippe Wittenbergh http://emps.l-c-n.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Title attribute and screen readers
Hi all, I'm looking for up to date info on title attribute behaviour screen readers, especially where used on site global navigation. As an example, http://www.e.govt.nz uses fairly long title attributes for the main navigation links, and this repeats throughout the site (i.e., not just on the home page). For example, About e-govt in the left nav has: a href=http://www.e.govt.nz/about-egovt; span title=E-government enables people to use digital technology to find and use New Zealand government information and services.About e-govt/span /a Main thing I'm wondering is, with a screen reader, if reading out of title attribute text is enabled, are you forced to listen to the full title text each time it is encountered, or can you skip over it? In the above example, the title attribute is applied to a span nested inside the link, rather than to the link itself - would this make any difference? (Comparing this to phone customer support or online banking services - some force you to listen to the full spiel about each option before you can do anything, others don't - they allow you to activate your menu choice without listening to the full explanatory message.) Or are most screen reader users not using title attribute text - some time ago there was an article published suggesting most had it disabled... Would appreciate any information anyone might have on how this works! Cheers, Rebecca *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Title attribute and screen readers
Hi Rebecca, announcing of title attribute values on links is not a default screen reader behaviour and for JAWS the announcing of the title attribute is an OR choice (read title or link content) so effectively the title attribute conentt for links is unavailable to most screen reader users. On 24/10/2007, Rebecca Cox [EMAIL PROTECTED] wrote: Hi all, I'm looking for up to date info on title attribute behaviour screen readers, especially where used on site global navigation. As an example, http://www.e.govt.nz uses fairly long title attributes for the main navigation links, and this repeats throughout the site (i.e., not just on the home page). For example, About e-govt in the left nav has: a href=http://www.e.govt.nz/about-egovt; span title=E-government enables people to use digital technology to find and use New Zealand government information and services.About e-govt/span /a Main thing I'm wondering is, with a screen reader, if reading out of title attribute text is enabled, are you forced to listen to the full title text each time it is encountered, or can you skip over it? In the above example, the title attribute is applied to a span nested inside the link, rather than to the link itself - would this make any difference? (Comparing this to phone customer support or online banking services - some force you to listen to the full spiel about each option before you can do anything, others don't - they allow you to activate your menu choice without listening to the full explanatory message.) Or are most screen reader users not using title attribute text - some time ago there was an article published suggesting most had it disabled... Would appreciate any information anyone might have on how this works! Cheers, Rebecca *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- 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 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Title attribute and screen readers
Hi Steve, If I may follow on to Rebecca's query and based your reply, is it then considered good practice (in general) _not_ to add title attributes and values to hyperlinks? Kind regards, Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Faulkner Sent: Wednesday, 24 October, 2007 11:20 AM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Title attribute and screen readers Hi Rebecca, announcing of title attribute values on links is not a default screen reader behaviour and for JAWS the announcing of the title attribute is an OR choice (read title or link content) so effectively the title attribute conentt for links is unavailable to most screen reader users. On 24/10/2007, Rebecca Cox [EMAIL PROTECTED] wrote: Hi all, I'm looking for up to date info on title attribute behaviour screen readers, especially where used on site global navigation. As an example, http://www.e.govt.nz uses fairly long title attributes for the main navigation links, and this repeats throughout the site (i.e., not just on the home page). For example, About e-govt in the left nav has: a href=http://www.e.govt.nz/about-egovt; span title=E-government enables people to use digital technology to find and use New Zealand government information and services.About e-govt/span /a Main thing I'm wondering is, with a screen reader, if reading out of title attribute text is enabled, are you forced to listen to the full title text each time it is encountered, or can you skip over it? In the above example, the title attribute is applied to a span nested inside the link, rather than to the link itself - would this make any difference? (Comparing this to phone customer support or online banking services - some force you to listen to the full spiel about each option before you can do anything, others don't - they allow you to activate your menu choice without listening to the full explanatory message.) Or are most screen reader users not using title attribute text - some time ago there was an article published suggesting most had it disabled... Would appreciate any information anyone might have on how this works! Cheers, Rebecca *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- 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 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Title attribute and screen readers
Frank Palinkas wrote: If I may follow on to Rebecca's query and based your reply, is it then considered good practice (in general) _not_ to add title attributes and values to hyperlinks? You can add them, but you must be aware that it's likely that screen reader users won't hear them by default. Also, sighted keyboard users will never see them either. You can add advisory/optional info in the title, but nothing that is critical to understanding what a link is/does. Most of the time, I find that it's better to ensure that the clearly visible link text is self-evident enough, and doing away with titles altogether. P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Title attribute and screen readers
Thanks Steven. Combined with Patrick's reply, and based on your experience and deep involvement with accessibility, this is indeed excellent, practical advice. Kind regards, Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Faulkner Sent: Wednesday, 24 October, 2007 12:17 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Title attribute and screen readers Hi Frank, I would suggest that if you want the information available to screen reader users or keyboard only users (as title attribute content is not available to keyboard users), then don't place it in the title attribute on links. On 24/10/2007, Frank Palinkas [EMAIL PROTECTED] wrote: Hi Steve, If I may follow on to Rebecca's query and based your reply, is it then considered good practice (in general) _not_ to add title attributes and values to hyperlinks? Kind regards, Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Faulkner Sent: Wednesday, 24 October, 2007 11:20 AM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Title attribute and screen readers Hi Rebecca, announcing of title attribute values on links is not a default screen reader behaviour and for JAWS the announcing of the title attribute is an OR choice (read title or link content) so effectively the title attribute conentt for links is unavailable to most screen reader users. On 24/10/2007, Rebecca Cox [EMAIL PROTECTED] wrote: Hi all, I'm looking for up to date info on title attribute behaviour screen readers, especially where used on site global navigation. As an example, http://www.e.govt.nz uses fairly long title attributes for the main navigation links, and this repeats throughout the site (i.e., not just on the home page). For example, About e-govt in the left nav has: a href=http://www.e.govt.nz/about-egovt; span title=E-government enables people to use digital technology to find and use New Zealand government information and services.About e-govt/span /a Main thing I'm wondering is, with a screen reader, if reading out of title attribute text is enabled, are you forced to listen to the full title text each time it is encountered, or can you skip over it? In the above example, the title attribute is applied to a span nested inside the link, rather than to the link itself - would this make any difference? (Comparing this to phone customer support or online banking services - some force you to listen to the full spiel about each option before you can do anything, others don't - they allow you to activate your menu choice without listening to the full explanatory message.) Or are most screen reader users not using title attribute text - some time ago there was an article published suggesting most had it disabled... Would appreciate any information anyone might have on how this works! Cheers, Rebecca *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- 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 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- 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 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Title attribute and screen readers
Hi Frank, I would suggest that if you want the information available to screen reader users or keyboard only users (as title attribute content is not available to keyboard users), then don't place it in the title attribute on links. On 24/10/2007, Frank Palinkas [EMAIL PROTECTED] wrote: Hi Steve, If I may follow on to Rebecca's query and based your reply, is it then considered good practice (in general) _not_ to add title attributes and values to hyperlinks? Kind regards, Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Faulkner Sent: Wednesday, 24 October, 2007 11:20 AM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Title attribute and screen readers Hi Rebecca, announcing of title attribute values on links is not a default screen reader behaviour and for JAWS the announcing of the title attribute is an OR choice (read title or link content) so effectively the title attribute conentt for links is unavailable to most screen reader users. On 24/10/2007, Rebecca Cox [EMAIL PROTECTED] wrote: Hi all, I'm looking for up to date info on title attribute behaviour screen readers, especially where used on site global navigation. As an example, http://www.e.govt.nz uses fairly long title attributes for the main navigation links, and this repeats throughout the site (i.e., not just on the home page). For example, About e-govt in the left nav has: a href=http://www.e.govt.nz/about-egovt; span title=E-government enables people to use digital technology to find and use New Zealand government information and services.About e-govt/span /a Main thing I'm wondering is, with a screen reader, if reading out of title attribute text is enabled, are you forced to listen to the full title text each time it is encountered, or can you skip over it? In the above example, the title attribute is applied to a span nested inside the link, rather than to the link itself - would this make any difference? (Comparing this to phone customer support or online banking services - some force you to listen to the full spiel about each option before you can do anything, others don't - they allow you to activate your menu choice without listening to the full explanatory message.) Or are most screen reader users not using title attribute text - some time ago there was an article published suggesting most had it disabled... Would appreciate any information anyone might have on how this works! Cheers, Rebecca *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- 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 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- 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 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Title attribute and screen readers
Patrick H. Lauke wrote: Also, sighted keyboard users will never see them either. If they use IE. Kind Regards -- Chris Price Choctaw [EMAIL PROTECTED] http://www.choctaw.co.uk Tel. 01524 825 245 Mob. 0777 451 4488 Beauty is in the Eye of the Beholder while Excellence is in the Hand of the Professional ~~~ -+- Sent on behalf of Choctaw Media Ltd -+- ~~~ Choctaw Media Limited is a company registered in England and Wales with company number 04627649 Registered Office: Lonsdale Partners, Priory Close, St Mary's Gate, Lancaster LA1 1XB United Kingdom *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Title attribute and screen readers
Also, sighted keyboard users will never see them either. If they use IE. although users of firefox can access the title attribute via the keyboard, there is no way for them to know that there is a title there to be queried, unlike mouse users who are presented with the title as a tooltp when they mouse over a link (or any other element). So effectively they will never be seen. Also there is no method that I know of to access the title attribute content in other browser (Opera etc) On 24/10/2007, Chris Price [EMAIL PROTECTED] wrote: Patrick H. Lauke wrote: Also, sighted keyboard users will never see them either. If they use IE. Kind Regards -- Chris Price Choctaw [EMAIL PROTECTED] http://www.choctaw.co.uk Tel. 01524 825 245 Mob. 0777 451 4488 Beauty is in the Eye of the Beholder while Excellence is in the Hand of the Professional ~~~ -+- Sent on behalf of Choctaw Media Ltd -+- ~~~ Choctaw Media Limited is a company registered in England and Wales with company number 04627649 Registered Office: Lonsdale Partners, Priory Close, St Mary's Gate, Lancaster LA1 1XB United Kingdom *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- 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 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Title attribute and screen readers
Chris Price wrote: Patrick H. Lauke wrote: Also, sighted keyboard users will never see them either. If they use IE. Or Firefox, or Safari, or Opera, ... Try tabbing to a link with a title via keyboard, and tell me if it brings up a tooltip or similar to let a sighted user read the title... P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Title attribute and screen readers
On Oct 24, 2007, at 4:27 AM, Patrick H. Lauke wrote: Try tabbing to a link with a title via keyboard, and tell me if it brings up a tooltip or similar to let a sighted user read the title... So it's concluded that title attribute is as useless as tabindex and accesskey and therefor shouldn't be used at all? Need acknowledge by your accessible mastero :) tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Title attribute and screen readers
So it's concluded that title attribute is as useless as tabindex and accesskey and therefor shouldn't be used at all? Need acknowledge by your accessible mastero :) Need acknowledge from your accessible mastero :-) tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Title attribute and screen readers
Patrick H. Lauke wrote: Chris Price wrote: Patrick H. Lauke wrote: Also, sighted keyboard users will never see them either. If they use IE. Or Firefox, or Safari, or Opera, ... Try tabbing to a link with a title via keyboard, and tell me if it brings up a tooltip or similar to let a sighted user read the title... P I stand corrected. Kind Regards -- Chris Price Choctaw [EMAIL PROTECTED] http://www.choctaw.co.uk Tel. 01524 825 245 Mob. 0777 451 4488 Beauty is in the Eye of the Beholder while Excellence is in the Hand of the Professional ~~~ -+- Sent on behalf of Choctaw Media Ltd -+- ~~~ Choctaw Media Limited is a company registered in England and Wales with company number 04627649 Registered Office: Lonsdale Partners, Priory Close, St Mary's Gate, Lancaster LA1 1XB United Kingdom *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Title attribute and screen readers
Chris Price wrote: I stand corrected. You can sit as well, it's fine :) P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] browsers render differently with Optroup
On Oct 24, 2007, at 12:14 AM, Philippe Wittenbergh wrote: On Oct 24, 2007, at 3:27 PM, Tee G. Peng wrote: I am working on a web form that has Optgroup in it, and the first time I realized browsers render this attribute differently. IE Mac displays 'CA' in your 1st example IE 7 Win displays 'CA' in your 1st example Opera 9.5 alpha: idem ditto. I made an example page with markup copied from the above page http://lotusfromthemud.com/option.html Under 17.6.1 it says (specifically for label in option): http://www.w3.org/TR/html401/interact/forms.html#adef-label-OPTION label = text [CS] This attribute allows authors to specify a shorter label for an option than the content of the OPTION element. When specified, user agents should use the value of this attribute rather than the content of the OPTION element as the option label. That sounds, to me, as validating what Safari, IE Mac, IE Win Camino are doing. Note that Firefox is not wrong by the description given above. I am sorry I only understand this thing half. We must use 'label' right? option label=3.7 value=pm2_3.7PortMaster 2 with ComOS 3.7/ option So Firefox reads PortMaster 2 with ComOS 3.7 and the rest of the browsers read from 'label' attribute, so the screen reader? Can 'value' be removed? Everytime I work on a web form, the same qeustion kept throwing back to me. Is there any attribute one can saftly remove without causing browsers, screen reader and form script suffer? label and ID are needed, Name also needed for the form script I use; this leaves the 'value' which I never able to decide the *value* of its usage. I really find a markup like this is too much label for=myformMy form /label input name=myform id=myform value=myform tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] browsers render differently with Optroup
On Oct 24, 2007, at 10:37 PM, Tee G. Peng wrote: Under 17.6.1 it says (specifically for label in option): http://www.w3.org/TR/html401/interact/forms.html#adef-label-OPTION label = text [CS] This attribute allows authors to specify a shorter label for an option than the content of the OPTION element. When specified, user agents should use the value of this attribute rather than the content of the OPTION element as the option label. That sounds, to me, as validating what Safari, IE Mac, IE Win Camino are doing. Note that Firefox is not wrong by the description given above. I am sorry I only understand this thing half. ... Can 'value' be removed? Everytime I work on a web form, the same qeustion kept throwing back to me. Is there any attribute one can saftly remove without causing browsers, screen reader and form script suffer? label and ID are needed, Name also needed for the form script I use; this leaves the 'value' which I never able to decide the *value* of its usage. I really find a markup like this is too much label for=myformMy form /label input name=myform id=myform value=myform I think you are confused :-) There is a difference between label the html _element_ and label the _attribute_ on option and optgroup element: label for=myformMy form /label input name=myform id=myform value=myform attribute select id=myselectoption label=mylabel value=myvaluestring in option/option/select The 'value' attribute on option (and other form controls) is required for back-end processing (so that your script knows what to do with all the stuff the form feeds it). The 'label' attribute is always optional and _can_ be used by the UA for display purposes. 'name' is also required to identify the form control. Philippe --- Philippe Wittenbergh http://emps.l-c-n.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] browsers render differently with Optroup
On 24 Oct 2007, at 14:37, Tee G. Peng wrote: We must use 'label' right? option label=3.7 value=pm2_3.7PortMaster 2 with ComOS 3.7/ option The label attribute is only required on optgroup; it is optional on option. If browsers are behaving differently when it's used on option, just remove it. http://www.w3.org/TR/html4/index/attributes.html is a quick way to check whether an attribute is required or not. Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Priority 2 error - Clearly identify the target of each link.
I agree with what everyone is saying, altough it is not always feasible to make the link text descriptive and sometimes makes it look clunky when you've added the read more link straight after the title, having to write read more about... and repeat the title again. All that aside, it is a requirement, so it must be followed. I did find Joe Clark's comments at @media interesting though. If you go to his speaker's notes and search for Headings and links read out of context, it's worth a read and a valid point. http://joeclark.org/appearances/atmedia2007/ Anyway, until it is no longer a requirement, I'll be making my links descriptive. On 21/10/2007, russ - maxdesign [EMAIL PROTECTED] wrote: You have given a good reason, still, I think that criteria should have room for flexibility (just as George has given the same reason) because, link texts in the articles aren't the same and the excerpt of the article should have given enough information for a user (including screen reader user) whether he wants to continue reading the full article. If my argument is prudent, I think validator should have something like Tee, I apologise if I misread your original post. You mentioned a ...'continue reading' link... and then mentioned ...more than one title attribute with 'continue reading' I assumed you were referring to the content of the link being the same for each link - like this: a href= title=continue readingcontinue reading/a a href= title=continue readingcontinue reading/a However, you may have been referring to the content of the title attribute only - like this: a href= title=continue readingUnique content/a a href= title=continue readingSome other content/a If this is the case, then I agree with Gunlaug - that this is much less of an issues. The title is designed to provide additional information, and is rarely used by assistive devices. As you say, Steve Faulkner has raised issues with the title attribute - even though his original article is not online, he gives a brief summary here: http://webstandardsgroup.org/features/steve-faulkner.cfm#seven due to its present support in browsers, it can actually add to making content less accessible. Guideline 13.1 states that Link text should be meaningful enough to make sense when read out of context. It goes on to say In addition... content developers may further clarify the target of a link with an informative link title. To me, this implies that this title is not essential. It could also be interpreted that as long as your content is meaningful and unique, you should pass this checkpoint. Someone with a deeper understanding of this checkpoint may be able to clarify this! Again, apologies for misreading and for any confusion. Thanks Russ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Floated list items of differing heights
Hi all, I've managed to avoid doing this for while, but I'm doing a CMS job and the content in a floated group of LI's is going to be differeing heights. They need to wrap onto a new line when they hit the right edge of the container, causing layout problems. I've found this article, but it doesn't work for me and seems like a lot of work. Has anyone see a better way of getting it to work? http://www.ruzee.com/blog/2007/05/align-list-items-horizontally-with-css/comment-page-1/ Cheers *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Title attribute and screen readers
Personally, I often still use the keyboard because I'm fast with it. And I really like good tabindexes. Why do you think they are useless? Regards, Rogier. On 24/10/2007, Tee G. Peng [EMAIL PROTECTED] wrote: So it's concluded that title attribute is as useless as tabindex and accesskey and therefor shouldn't be used at all? Need acknowledge by your accessible mastero :) Need acknowledge from your accessible mastero :-) tee Great addition Tee, not everybody is a native english speaker :) *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Minimum width help
Can someone explain why I am generating a horizontal scroll bar at 1024 width? http://www3.andersrice.com/ Thanks, Dean *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Title attribute and screen readers
I use keyboard controls a lot too, and generally regard the use of tabindex as a sign that a site was not designed properly in the first place. It causes a number of problems such as being unable to predict where the focus is going to go next. How can the designer predict what the user will want to do except in really trivial cases such as Google's home page? It can be utterly baffling for screen reader users because the sequence of elements is different in 'forms' mode (where tabindex is followed) and 'virtual cursor' mode (where it cannot be followed). I saw this recently in a user test on a site that sadly has to remain nameless because we are under an NDA (it only went live this year and they didn't fix it). Can you provide any examples of sites that use tabindex well? Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rogier Schoenmaker Sent: 24 October 2007 20:51 To: wsg@webstandardsgroup.org Subject: Re: [WSG] Title attribute and screen readers Personally, I often still use the keyboard because I'm fast with it. And I really like good tabindexes. Why do you think they are useless? Regards, Rogier. On 24/10/2007, Tee G. Peng [EMAIL PROTECTED] wrote: So it's concluded that title attribute is as useless as tabindex and accesskey and therefor shouldn't be used at all? Need acknowledge by your accessible mastero :) Need acknowledge from your accessible mastero :-) tee Great addition Tee, not everybody is a native english speaker :) *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Minimum width help
Hi Dean,
Not sure what these two styles are actually doing but it looks like
they're the cause within your menu.css
#p7TBMsub03 { padding: 0 0 0 150px; }
#p7TBMsub04 { padding: 0 0 0 210px; }
Removing them seems to fix the problem with no adverse effect.
Cheers
Dave
- - - - - - - - - -
Dave Woods
http://www.dave-woods.co.uk
On 24/10/2007, Dean Matthews [EMAIL PROTECTED] wrote:
Can someone explain why I am generating a horizontal scroll bar at
1024 width?
http://www3.andersrice.com/
Thanks,
Dean
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Minimum width help
Actually, further investigation, I've spotted what's happening.
You're hiding the submenu's using this
.p7TBMsub {
position: absolute;
visibility:hidden;
left: 0;
top: 0;
width: 100%;
}
But then you're forgetting that the 100% width is being combined with
the padding and therefore forcing your page out by 210px.
You could take my original suggestion and remove the padding but the
better suggestion would be just to remove the width: 100%;
You're applying it to a block element which by default is 100% anyway
but by not applying it, the width will take into consideration the
other padding you're applying automatically.
So, change your code to this and it should work ;o)
.p7TBMsub {
position: absolute;
visibility:hidden;
left: 0;
top: 0;
}
Although, I'm not sure whether using visibility: hidden; will be bad
for screenreaders as I know display: none; will and you're doing a
similar thing so you may be better going for the suckerfish menu
approach where you position the hidden menu using offscreen negative
positioning.
http://www.htmldog.com/articles/suckerfish/dropdowns/
But that's a different matter altogether.
Hope that helps.
- - - - - - - - - -
Dave Woods
http://www.dave-woods.co.uk
On 24/10/2007, Dave Woods [EMAIL PROTECTED] wrote:
Hi Dean,
Not sure what these two styles are actually doing but it looks like
they're the cause within your menu.css
#p7TBMsub03 { padding: 0 0 0 150px; }
#p7TBMsub04 { padding: 0 0 0 210px; }
Removing them seems to fix the problem with no adverse effect.
Cheers
Dave
- - - - - - - - - -
Dave Woods
http://www.dave-woods.co.uk
On 24/10/2007, Dean Matthews [EMAIL PROTECTED] wrote:
Can someone explain why I am generating a horizontal scroll bar at
1024 width?
http://www3.andersrice.com/
Thanks,
Dean
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
RE: [WSG] Minimum width help
visibility: hidden does hide the content from screen readers the same as
display:none does.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dave Woods
Sent: 24 October 2007 22:04
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] Minimum width help
Actually, further investigation, I've spotted what's happening.
You're hiding the submenu's using this
.p7TBMsub {
position: absolute;
visibility:hidden;
left: 0;
top: 0;
width: 100%;
}
But then you're forgetting that the 100% width is being combined with the
padding and therefore forcing your page out by 210px.
You could take my original suggestion and remove the padding but the better
suggestion would be just to remove the width: 100%;
You're applying it to a block element which by default is 100% anyway but by
not applying it, the width will take into consideration the other padding
you're applying automatically.
So, change your code to this and it should work ;o)
.p7TBMsub {
position: absolute;
visibility:hidden;
left: 0;
top: 0;
}
Although, I'm not sure whether using visibility: hidden; will be bad for
screenreaders as I know display: none; will and you're doing a similar thing
so you may be better going for the suckerfish menu approach where you
position the hidden menu using offscreen negative positioning.
http://www.htmldog.com/articles/suckerfish/dropdowns/
But that's a different matter altogether.
Hope that helps.
- - - - - - - - - -
Dave Woods
http://www.dave-woods.co.uk
On 24/10/2007, Dave Woods [EMAIL PROTECTED] wrote:
Hi Dean,
Not sure what these two styles are actually doing but it looks like
they're the cause within your menu.css
#p7TBMsub03 { padding: 0 0 0 150px; }
#p7TBMsub04 { padding: 0 0 0 210px; }
Removing them seems to fix the problem with no adverse effect.
Cheers
Dave
- - - - - - - - - -
Dave Woods
http://www.dave-woods.co.uk
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
RE: [WSG] Minimum width help
visibility: hidden does hide the content from screen readers the same as display:none does. And it may get your site banned from search engines if overused: http://www.google.com/support/webmasters/bin/answer.py?answer=66353 What I've done for accesskey code is use this: position: absolute; left: -px; width: 1px; From what I've learnt this allows access to the text to screen readers but regular browsers don't see it. I'm not aware of any SEO issues with this. Our site doesn't seem to have been affected... Paul *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Minimum width help
On Oct 24, 2007, at 5:04 PM, Dave Woods wrote: You could take my original suggestion and remove the padding but the better suggestion would be just to remove the width: 100%; Thanks for the assist Dave. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Minimum width help
Not in Safari Dean! Tom On 24 Oct 2007, at 21:05, Dean Matthews wrote: Can someone explain why I am generating a horizontal scroll bar at 1024 width? http://www3.andersrice.com/ Thanks, Dean *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Improving Website Image and Map Accessibility
Posted an article on this topic yesterday. Would be interested to hear what you lot have to say about it: :) http://www.datalink.com.au/company/emagination/webdev/improving_website_image_and_map_accessibility_ Regards, Karl Lurman *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Opera for Nintendo Wii and CSS
I've been looking around the Opera site, but can't find answers to the following: Does Opera on the Wii support handlheld and/or projection stylesheets? SVG? Also, is SVG supported on the Nintendo DS browser? Thanks, Geoff. == The information contained in this email and any attachment is confidential and may contain legally privileged or copyright material. It is intended only for the use of the addressee(s). If you are not the intended recipient of this email, you are not permitted to disseminate, distribute or copy this email or any attachments. If you have received this message in error, please notify the sender immediately and delete this email from your system. The ABC does not represent or warrant that this transmission is secure or virus free. Before opening any attachment you should check for viruses. The ABC's liability is limited to resupplying any email and attachments == *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Opera for Nintendo Wii and CSS
Seeing as it looks like your developing for the browser without actually having a Wii. I believe the PAL resolution is 480p (720x480). Obviously also just take care not to have anything too fancy as it may be difficult to interact with. Geoff Pack wrote: I've been looking around the Opera site, but can't find answers to the following: Does Opera on the Wii support handlheld and/or projection stylesheets? SVG? Also, is SVG supported on the Nintendo DS browser? Thanks, Geoff. == The information contained in this email and any attachment is confidential and may contain legally privileged or copyright material. It is intended only for the use of the addressee(s). If you are not the intended recipient of this email, you are not permitted to disseminate, distribute or copy this email or any attachments. If you have received this message in error, please notify the sender immediately and delete this email from your system. The ABC does not represent or warrant that this transmission is secure or virus free. Before opening any attachment you should check for viruses. The ABC's liability is limited to resupplying any email and attachments == *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Floated list items of differing heights
I've managed to avoid doing this for while, but I'm doing a CMS job and the content in a floated group of LI's is going to be differeing heights. They need to wrap onto a new line when they hit the right edge of the container, causing layout problems. Would need to see what you have at the moment before I could suggest anything. -- Tyssen Design www.tyssendesign.com.au Ph: (07) 3300 3303 Mb: 0405 678 590 *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
