Re: [WSG] screen reader friendly and keyboard accessible popup?

2011-02-26 Thread tee
 
On Feb 24, 2011, at 9:57 PM, Thierry Koblentz wrote:
 
 
 If you use anything other than buttons or links make sure to use tabindex=0
 to make your elements focusable via keyboard, and attached role=button to
 it.
 
 As a side note, the challenge with collapsing panels is to let users
 open/close panels, but at the same time make all focusable items in the
 hidden panels non focusable, or simply remove the panels via display:none.
 The challenge is to expose content to SE, but at the same time allow keybord
 users to navigate the documents without having to go through everything
 focusable item in the document (in all panels, collapsed or not). If we
 implement collapsible panels in the first place it is to minimize content
 overload - so imho it should be the same for all users.
 

Thanks for the reminder!

tee


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



RE: [WSG] screen reader friendly and keyboard accessible popup?

2011-02-25 Thread Smith, Jamie
After the click me link is selected a person using speech read

 Keyboard Accessible Popup
Click me - This is keyboard accessible, but will the empty link creates
redundant noise for screen reader?

Lorem ipsum dolor sit amet, consectetuer adipiscing elit.

Close
 Click me

The person did not like the redundant text and wonder why a regular
message box wasn't used.


-Original Message-
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org]
On Behalf Of tee
Sent: Wednesday, February 23, 2011 5:21 AM
To: wsg@webstandardsgroup.org
Subject: [WSG] screen reader friendly and keyboard accessible popup?

Please take a look at this example. The first example is keyboard
accessible however I am also concern with the empty link that may create
extra noise for screen reader, e.g if every single page has a popup, it
will have two empty links, one is the popup trigger and the other the
close link. Sure it's just two empty links, as I started using VoiceOver
more frequent to test the sites, I find the two links quite annoying.

http://jsbin.com/efimu5

Is there a much better approach that works great for both keyboard and
screen reader user? Was looking up the keypress and focus events,
but not certain they are good for such function.

Thanks!


tee

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] screen reader friendly and keyboard accessible popup?

2011-02-25 Thread Andrew Boyd
On Sat, Feb 26, 2011 at 8:11 AM, Smith, Jamie jamie.sm...@dbs.fldoe.org wrote:
 After the click me link is selected a person using speech read

  Keyboard Accessible Popup
 Click me - This is keyboard accessible, but will the empty link creates
 redundant noise for screen reader?

 Lorem ipsum dolor sit amet, consectetuer adipiscing elit.

 Close
  Click me

 The person did not like the redundant text and wonder why a regular
 message box wasn't used.

Jamie,

this just proves to me that nobody really likes Lorem ipsum... :)

Seriously though, I am not sure I get what you are saying. Is the
problem that the link text is read twice to the screen reader user?
And just out of interest, which screen reader were they using?

Best regards, Andrew


-- 
---
Andrew Boyd
http://uxbookclub.org -- connect, read, discuss


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] screen reader friendly and keyboard accessible popup?

2011-02-25 Thread tee
 
On Feb 25, 2011, at 2:21 PM, Andrew Boyd wrote:
 
 Jamie,
 
 this just proves to me that nobody really likes Lorem ipsum... :)


I used to use the first paragraph of Italo Calvino's If on a Winter's Night a 
Traveler for such purpose. Someone wrote me off list (not from this list) 
gently warned me I violated both the Italian writer and English translator 
copyrights, and suggested I should use Lorem ipsum :---)

tee




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] screen reader friendly and keyboard accessible popup?

2011-02-24 Thread tee
Thierry, 

Thanks for the suggestion! It got me think of a few things. 

Structurally and semantically, do you find a  distinctive difference between 
Modal and Collapsible? 

I wanted to make sure I am on the right track; when I think of the use of Modal 
Window, I think of a block of content that is not part of the main content in a 
given page, e.g. a Ajax fetch, an image gallery (which makes use of the herf 
link to pull the larger image), a dialog box, a content in the aside element. 
The choice of the Modal Window, is not so much of a UI/Design choice but the 
integrity of content structure and that it does not obscured the flow of the 
content when AT is used, so making sure the focus brought back to the original 
trigger is something that needs to deal with - a Modal script I use, doesn't 
offered this feature, it jumps back to the first link.

With Collapsible, it's largely a UI/Design choice,  structurally,  the content 
in it is part of the main content, it's just a simple show/hide that makes good 
use of space, and apart from button that you recommended, a heading can be 
served as a trigger too depending on the content (for the site I was working, 
in a few pages heading is more appropriate, as in other pages , button is 
indeed better than p tag). With Collapsible, we don't normally provide a close 
button. What I was trying to do with this pop up, is a simple modified 
version of Collapsible (show/hide) that the Collapsible's container uses 
absolute positioning, thus a close button is provided, and when closed, it will 
goes back, not to the original trigger but the link after the trigger. I do not 
see any issue about with this, but would love to hear how you guys think about 
it.

Lastly, I guess there isn't any  benefit to use ARIA role just for this pop 
up when the entire site is not made for it (it's not a simple WordPress blog 
that consists of a handful of template files but eCommerce site with hundred of 
template files and it will be an enormous task. I am however have been slowly 
building a HTML5 theme with ARIA support for it from scratch, but it likely 
won't be finished until next year as I feel there is so much needed to know 
about the proper use of ARIA).

tee

On Feb 23, 2011, at 9:33 AM, Thierry Koblentz wrote:

 Hi Tee,
 
 Please take a look at this example. The first example is keyboard
 accessible however I am also concern with the empty link that may
 create extra noise for screen reader, e.g if every single page has a
 popup, it will have two empty links, one is the popup trigger and the
 other the close link. Sure it's just two empty links, as I started
 using VoiceOver more frequent to test the sites, I find the two links
 quite annoying.
 
 http://jsbin.com/efimu5
 
 I'd use buttons instead of links, or I'd add role=button to the links.
 I'd also add role=alertdialog  to the modal, making sure that the focus
 goes to the close button/link within the modal and also making sure that
 when the user closes the modal, focus is brought back to the original
 trigger.
 
 See: http://www.w3.org/TR/wai-aria/roles



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] screen reader friendly and keyboard accessible popup?

2011-02-24 Thread tee
On Feb 24, 2011, at 2:19 AM, tee wrote:
  
 making sure the focus brought back to the original trigger is something that 
 needs to deal with - a Modal script I use, doesn't offered this feature, it 
 jumps back to the first link.

Maybe not! 
http://jsbin.com/awidi4

But the browsers behave differently so I am not sure if it's a script issue or 
the browsers - using the tab navigation, the close button seems getting in the 
way also.

Firefox appears to be getting right - tab through the gallery or escape it  
halfway (by pressing the escape key) and/or without using arrow key to 
navigation the gallery in the Modal window, it's being brought to the next link 
from the link where you escaped, whereas Webkit goes back to the first link if  
arrow key has not  been used.

For Ajax fetch, it's the same but because there is no focus for Google site 
it's difficult to tell which is the last link. Not sure if it's iFrame, I am 
not able to escape halfway within the Google page.



tee



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



RE: [WSG] screen reader friendly and keyboard accessible popup?

2011-02-24 Thread Thierry Koblentz
 With Collapsible, it's largely a UI/Design choice,  structurally,  the
 content in it is part of the main content, it's just a simple show/hide
 that makes good use of space, and apart from button that you
 recommended, a heading can be served as a trigger too depending on the
 content (for the site I was working, in a few pages heading is more
 appropriate, as in other pages , button is indeed better than p tag).

If you use anything other than buttons or links make sure to use tabindex=0
to make your elements focusable via keyboard, and attached role=button to
it.

As a side note, the challenge with collapsing panels is to let users
open/close panels, but at the same time make all focusable items in the
hidden panels non focusable, or simply remove the panels via display:none.
The challenge is to expose content to SE, but at the same time allow keybord
users to navigate the documents without having to go through everything
focusable item in the document (in all panels, collapsed or not). If we
implement collapsible panels in the first place it is to minimize content
overload - so imho it should be the same for all users.

--
Regards,
Thierry
@thierrykoblentz
www.tjkdesign.com | www.ez-css.org | www.css-101.org 






***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



[WSG] screen reader friendly and keyboard accessible popup?

2011-02-23 Thread tee
Please take a look at this example. The first example is keyboard accessible 
however I am also concern with the empty link that may create extra noise for 
screen reader, e.g if every single page has a popup, it will have two empty 
links, one is the popup trigger and the other the close link. Sure it's just 
two empty links, as I started using VoiceOver more frequent to test the sites, 
I find the two links quite annoying.

http://jsbin.com/efimu5

Is there a much better approach that works great for both keyboard and screen 
reader user? Was looking up the keypress and focus events, but not certain 
they are good for such function.

Thanks!


tee

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



RE: [WSG] screen reader friendly and keyboard accessible popup?

2011-02-23 Thread Foskett, Mike
Just a few thoughts.

It would be better if the keyboard link had an id reference in it.

a id=openPopup1 href=#popup1pop-up/a

And the associated div had an id:

div id=popup1...

The close link references the opening link:

a href=#openPopup1Close/a

Also shift the pop-up off-screen rather than display:none

#popup1 {position: absolute; left:-500em; top:0}

Or at very least check JavaScript is enabled before hiding it using display:none

.hasJS #popup1 {display:none}

Add the .hasJS class to the html element like so:

script 
type=text/javascript/*![CDATA[*/document.documentElement.className=hasJS;/*]]*//script

Which should be the first line in the head section.



I wouldn't personally use the second non-keyboard method.



Regards


Mike Foskett
http://websemantics.co.uk/


-Original Message-
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On 
Behalf Of tee
Sent: 23 February 2011 10:21
To: wsg@webstandardsgroup.org
Subject: [WSG] screen reader friendly and keyboard accessible popup?

Please take a look at this example. The first example is keyboard accessible 
however I am also concern with the empty link that may create extra noise for 
screen reader, e.g if every single page has a popup, it will have two empty 
links, one is the popup trigger and the other the close link. Sure it's just 
two empty links, as I started using VoiceOver more frequent to test the sites, 
I find the two links quite annoying.

http://jsbin.com/efimu5

Is there a much better approach that works great for both keyboard and screen 
reader user? Was looking up the keypress and focus events, but not certain 
they are good for such function.

Thanks!


tee

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***


This is a confidential email. Tesco may monitor and record all emails. The 
views expressed in this email are those of the sender and not Tesco.

Tesco Stores Limited
Company Number: 519500
Registered in England
Registered Office: Tesco House, Delamare Road, Cheshunt, Hertfordshire EN8 9SL
VAT Registration Number: GB 220 4302 31


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] screen reader friendly and keyboard accessible popup?

2011-02-23 Thread Chad Kelly

On 2/23/2011 9:20 PM, tee wrote:

Please take a look at this example. The first example is keyboard accessible 
however I am also concern with the empty link that may create extra noise for 
screen reader, e.g if every single page has a popup, it will have two empty 
links, one is the popup trigger and the other the close link. Sure it's just 
two empty links, as I started using VoiceOver more frequent to test the sites, 
I find the two links quite annoying.

http://jsbin.com/efimu5

Is there a much better approach that works great for both keyboard and screen reader user? Was 
looking up the keypress and focus events, but not certain they are good for 
such function.

Pop-ups are a hard thing to get correct for accessibility.
As is the case for everything else some screen readers handle them 
better then others.





***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] screen reader friendly and keyboard accessible popup?

2011-02-23 Thread Chad Kelly

On 2/23/2011 10:37 PM, Foskett, Mike wrote:

Just a few thoughts.

It would be better if the keyboard link had an id reference in it.

 a id=openPopup1 href=#popup1pop-up/a

And the associated div had an id:

 div id=popup1...

The close link references the opening link:

 a href=#openPopup1Close/a

Also shift the pop-up off-screen rather than display:none

 #popup1 {position: absolute; left:-500em; top:0}

Or at very least check JavaScript is enabled before hiding it using display:none

 .hasJS #popup1 {display:none}

Add the .hasJS class to the html element like so:

 script 
type=text/javascript/*![CDATA[*/document.documentElement.className=hasJS;/*]]*//script

Which should be the first line in the head section.



I don't think hiding the display of the pop up will be necessary, as 
mobile device users could use the keyboard functionality as well.




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] screen reader friendly and keyboard accessible popup?

2011-02-23 Thread tee
 
a id=openPopup1 href=#popup1pop-up/a
 
 And the associated div had an id:
 
div id=popup1...
 
 The close link references the opening link:
 
a href=#openPopup1Close/a
 
 Also shift the pop-up off-screen rather than display:none
 
#popup1 {position: absolute; left:-500em; top:0}



Thanks Mike and Chad,

Curious, is there particular benefit to assign ID for such function concerning 
accessibility and AT?  

 
 
 
 Pop-ups are a hard thing to get correct for accessibility.
 As is the case for everything else some screen readers handle them better 
 then others.
 

Maybe true in the old dasy.

The use of such Popup is more of a design consideration (e.g. spacing saving) 
and it obscures no accessibility as far as content is concerned,  therefore I 
do not see the real needs to assign ID (though part of the reason is that I try 
to avoid inserting more codes into template files and write extra lines of 
javascript).

P/s. There is no display none in the example's markup. I never picked up that 
bad habit.

tee



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



RE: [WSG] screen reader friendly and keyboard accessible popup?

2011-02-23 Thread Thierry Koblentz
Hi Tee,

 Please take a look at this example. The first example is keyboard
 accessible however I am also concern with the empty link that may
 create extra noise for screen reader, e.g if every single page has a
 popup, it will have two empty links, one is the popup trigger and the
 other the close link. Sure it's just two empty links, as I started
 using VoiceOver more frequent to test the sites, I find the two links
 quite annoying.
 
 http://jsbin.com/efimu5

I'd use buttons instead of links, or I'd add role=button to the links.
I'd also add role=alertdialog  to the modal, making sure that the focus
goes to the close button/link within the modal and also making sure that
when the user closes the modal, focus is brought back to the original
trigger.

See: http://www.w3.org/TR/wai-aria/roles


--
Regards,
Thierry
@thierrykoblentz
www.tjkdesign.com | www.ez-css.org | www.css-101.org 


  



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***