Re: [WSG] screen reader friendly and keyboard accessible popup?
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?
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?
On Sat, Feb 26, 2011 at 8:11 AM, Smith, Jamie 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?
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?
> 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 ***
Re: [WSG] screen reader friendly and keyboard accessible popup?
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?
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?
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 ***
Re: [WSG] screen reader friendly and keyboard accessible popup?
>pop-up
>
> And the associated div had an id:
>
>...
>
> The close link references the opening link:
>
>Close
>
> 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?
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.
pop-up
And the associated div had an id:
...
The close link references the opening link:
Close
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:
/**/
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?
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?
Just a few thoughts.
It would be better if the keyboard link had an id reference in it.
pop-up
And the associated div had an id:
...
The close link references the opening link:
Close
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:
/**/
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
***
