Re: [WSG] Opera for Nintendo Wii and CSS

[Joshua Street]

On 10/25/07, Jixor - Stephen I <[EMAIL PROTECTED]> wrote:
> 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.

NTSC is 420p/i, PAL has 576 lines of vertical resolution. Also 720
wide. It will display at 25Hz at full-frame resolution, but I doubt
very much whether most video content on the web is even approaching
25fps, much less that the Wii is capable of rendering full-frame (i.e.
not-interlaced) web video without hardware accelleration... which it
might have, but not that I've heard of. I seem to recall a friend
using his Wii to playback Youtube content, so it certainly can deal
with video in some capacity... just don't go pushing tremendous frame
rates or high-def H264 content ;-)

-- 
Joshua Street

http://josh.st/blog/
+61 (0) 425 808 469


***
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

[Matthew Pennell]

On 24/10/2007, Paul Collins <[EMAIL PROTECTED]> wrote:
>
> I've managed to avoid doing this for  while, but I'm doing a CMS job
> and the content in a floated group of '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.
>

You either need to force the list items to all occupy the same height, by
using a fixed height, or use a server-side counter that sets "clear: left"
on every Nth item.

-- 




Matthew Pennell //
m: 07904 432123 //
www.thewatchmakerproject.com


***
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

[John Faulds]

I've managed to avoid doing this for  while, but I'm doing a CMS job
and the content in a floated group of '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]
***

Re: [WSG] Opera for Nintendo Wii and CSS

[Jixor - Stephen I]

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]
***

[WSG] Opera for Nintendo Wii and CSS

[Geoff Pack]

 
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]
***

[WSG] Improving Website Image and Map Accessibility

[Karl Lurman]

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]
***

Re: [WSG] Minimum width help

[Tom Roper]

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?




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

[Dean Matthews]

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

[Paul Bennett]

> 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

[Steve Green]

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

[Dave Woods]

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?
> >
> > 
> >
> > 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

[Dave Woods]

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?
>
> 
>
> 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] Title attribute and screen readers

[Steve Green]

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]
***

[WSG] Minimum width help

[Dean Matthews]

Can someone explain why I am generating a horizontal scroll bar at  
1024 width?




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

[Rogier Schoenmaker]

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] Floated list items of differing heights

[Paul Collins]

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 '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] Priority 2 error - Clearly identify the target of each link.

[Paul Collins]

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:
> continue reading
> continue reading
>
> However, you may have been referring to the content of the title attribute
> only - like this:
> Unique content
> Some other content
>
> 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]
***

Re: [WSG] browsers render differently with "Optroup"

[Nick Fitzsimons]

On 24 Oct 2007, at 14:37, Tee G. Peng wrote:


We must use 'label' right?

  PortMaster 2 with ComOS 3.7option>




The label attribute is only required on ; it is optional on  
. If browsers are behaving differently when it's used on  
, just remove it.


 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] browsers render differently with "Optroup"

[Philippe Wittenbergh]

On Oct 24, 2007, at 10:37 PM, Tee G. Peng wrote:


Under 17.6.1 it says (specifically for label in 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
My form 



I think you are confused :-)
There is a difference between  the html _element_ and label  
the _attribute_ on  and 


element:
My form 


attribute
string  
in option


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






***
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"

[Tee G. Peng]

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):


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?

  PortMaster 2 with ComOS 3.7option>


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
My form 



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]

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] Title attribute and screen readers

[Chris Price]

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

[Tee G. Peng]

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

[Tee G. Peng]

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

[Philippe Wittenbergh]

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...


In Firefox 2.0, a keyboard user can see the title attribute, but  
_only_ for images.

Under Tools > Page Info (command+I on Mac), select the media tab.

But that is going away Firefox 3, where the whole Page Info window  
has been greatly simplified.  The reasoning being: most of this could  
be added by an extension. And I think there is one under development,  
not sure.


Philippe
---
Philippe Wittenbergh






***
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]

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

[Steven Faulkner]

> > 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]

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

[Frank Palinkas]

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:
> >
> > http://www.e.govt.nz/about-egovt";>
> >About e-govt
> > 
> >
> > 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

[Frank Palinkas]

Thanks Patrick. That answers my question, and reinforces the importance of
employing clear, and concise link text.  

Kind regards,

Frank

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Patrick H. Lauke
Sent: Wednesday, 24 October, 2007 12:10 PM
To: wsg@webstandardsgroup.org
Subject: 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]
***



***
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

[Steven Faulkner]

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:
> >
> > http://www.e.govt.nz/about-egovt";>
> >About e-govt
> > 
> >
> > 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]

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

[Frank Palinkas]

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:
>
> http://www.e.govt.nz/about-egovt";>
>About e-govt
> 
>
> 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

[Steven Faulkner]

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:
>
> http://www.e.govt.nz/about-egovt";>
>About e-govt
> 
>
> 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]
***

[WSG] Title attribute and screen readers

[Rebecca Cox]

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:

http://www.e.govt.nz/about-egovt";>
About e-govt


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] browsers render differently with "Optroup"

[Philippe Wittenbergh]

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):


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






***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***