#21334 closed defect (bug) (fixed)
Row actions are not always keyboard accessible
Reported by: | grahamarmfield | Owned by: | helen |
---|---|---|---|
Milestone: | 3.7 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Accessibility | Keywords: | has-patch 3.7-early |
Focuses: | Cc: |
Description
Two issues here:
1) When someone using mouse hovers over a page/post row in main Pages/Posts screen - the 'quick links' appear. However these links will never appear when a user is tabbing around the screens - perhaps a blind user with screen reader or someone who is unable to use a mouse.
Please can the 'quick links' panel be opened when someone tabs to the page/post title and stay open so that they can then tab into the links provided.
2) Using Quick Edit.
When the Quick Edit panel is open the input fields in there are all nicely accessible except for the date and time grouping. These input fields have a tabindex value set (unlike the surrounding input fields) which removes them far from the natural sensible tab order within this panel. Suggest the tabindex values are removed.
Also, none of the date and time input fields have labels so their meaning is unclear - certainly to blind users but also potentially to people with cognitive impairments too. Please can this be rectified.
Thanks
Attachments (17)
Change History (77)
#2
@
12 years ago
i was not able to conform the second issue, tabbing thru the date/time fields in quick edit worked fine in chrome and firefox on my mac, and i do not see the tabindex values mentioned.
the first issue can't be resolved with the css :focus pseudo-selector like the existing :hover class (tried briefly), because td doesn't get focus event unless it has tabindex. why don't elements have tabindex values, i'm sure there is a reason!
the only route to make this more accessible and keep the current hover action is with jquery, i am attaching a patch that traverses the dom and shoes the quick links section when the user focuses into the a href tag of a post title. the effect is that when tabbing thru the posts, the quick links section shows for each post when you highlight the post title.
notes:
-because the jquery adds the css( 'visbility', 'visible') the quick links stay visible and will not auto hide even when hovering. i think thats ok, the event is only triggered in a tab in as far as i know, so leaving the links visible is fine. if the user isn't tabbing around the links will behave as usual.
-navigating by tab, including into quick edit, and date fields works fine with this patch
-why are we hiding the quick links anyway? does it really make it easier to use? what about dimming to a gray that would still be accessible, but not distracting, then have the hover turn the links to black?
#3
@
12 years ago
here is an alternate patch that just changes the css to use opacity instead on previous visibility. it starts with the link area dimmed to 50% opacity until you hover over when it goes to 100%. of course its accessible because the quick links area is never hidden.
#5
@
12 years ago
this bug also affects 3.5, not sure how to indicate that in trac, version dropdown ends at 3.4.1
#8
in reply to:
↑ 7
;
follow-up:
↓ 9
@
12 years ago
Replying to markjaquith:
Just refreshed it to be patched from the root.
i'm going to revisit this ticket. what about just skipping the entire hide/show thing and leave the quick links visible at all time?
#9
in reply to:
↑ 8
;
follow-up:
↓ 10
@
12 years ago
Replying to adamsilverstein:
Replying to markjaquith:
Just refreshed it to be patched from the root.
i'm going to revisit this ticket. what about just skipping the entire hide/show thing and leave the quick links visible at all time?
From an accessibility perspective having links always visible is usually a good thing. However, I'm conscious that this would multiply quite considerably the number of links permanently visible on a page.
Perhaps alternative functionality could be:
- Quick links become visible when mouse hovers over item - as per now.
- An extra link is provided to the right or just below Title of page/post which says 'show quick links'. When this link is actioned the links become visible for that item only. The last link in the quick links could be 'hide quick links'.
Another alternative would be to include an option in the Screen Options panel that would allow users to select that they want quick links to be always visible.
Any quick links or show/hide links that are visible would need to include context to identify which item they refer to. This can be done by overloading the links with the context text hidden using the screenreadertxt (?) CSS class that is available within the WP admin area.
Eg: <a href="blah">Show quick links<span class="screenreadertxt"> for Post Title</span></a>
In this way the links will all make sense to screen reader users who are using the facility to list all links on a page.
Happy to discuss further if required.
#10
in reply to:
↑ 9
@
12 years ago
please review the new diff attached (21334-2.diff) - i added show quick links/hide quick links with the screen reader hints as you suggested... and some tabindex statements. i still can't tab in correctly in firefox, but chrome works great from the keyboard, no sure why firefox seems to skip these fields entirely.
certainly works better than before the patch and it maintains the hidden/hover on mouse over. let me know what you think.
Replying to grahamarmfield:
Replying to adamsilverstein:
Replying to markjaquith:
Just refreshed it to be patched from the root.
i'm going to revisit this ticket. what about just skipping the entire hide/show thing and leave the quick links visible at all time?
From an accessibility perspective having links always visible is usually a good thing. However, I'm conscious that this would multiply quite considerably the number of links permanently visible on a page.
Perhaps alternative functionality could be:
- Quick links become visible when mouse hovers over item - as per now.
- An extra link is provided to the right or just below Title of page/post which says 'show quick links'. When this link is actioned the links become visible for that item only. The last link in the quick links could be 'hide quick links'.
Another alternative would be to include an option in the Screen Options panel that would allow users to select that they want quick links to be always visible.
Any quick links or show/hide links that are visible would need to include context to identify which item they refer to. This can be done by overloading the links with the context text hidden using the screenreadertxt (?) CSS class that is available within the WP admin area.
Eg: <a href="blah">Show quick links<span class="screenreadertxt"> for Post Title</span></a>
In this way the links will all make sense to screen reader users who are using the facility to list all links on a page.
Happy to discuss further if required.
#11
follow-up:
↓ 12
@
12 years ago
Tabindex is "evil" :)
It breaks the natural flow of tabbing affecting negatively all users, and behaves differently in different browsers when added to elements that can be shown/hidden or are moved in the DOM.
A better way to fix this may be to make the table cell (or row?) "focusable" and show these links on focus. This should also be tested on touch devices.
#12
in reply to:
↑ 11
;
follow-up:
↓ 13
@
12 years ago
thanks for the info, i will banish 'tabindex' from all future code! i only added them so i could tab into the link (for testing), but i think i can fix that by using a table structure more carefully in the layout as you suggested.
my 1st patch did closer to what you suggest (almost) by hiding/showing the quicklinks when tabbing into the field above them; then ticket opener @grahamarmfield suggested that a show quick links/hide quick links setup would be more accessible, especially for screen readers, note the show and hide links include the screen reader context info.
i really value your opinion here, can you help me decide the best resolution, i see these options:
- show quick links at all times, remove hover on/off code - i like this the best personally
- use current method - show/hide quicklinks (but with no tabindex and more browser testing for tab layout); also keeps existing hover on/off effect
- method where links show when row or cell gains focus
not sure how to make cell focusable in version 3, or if it will fire even when entered by tab on all browsers, or if will work at all on touch devices. i think i tried this route originally and wasn't getting events i expected when tabbing into the cell.
versions 1 & 2 seem to be the most accessible which is what we are trying to address here. what do you think?
Replying to azaozz:
Tabindex is "evil" :)
It breaks the natural flow of tabbing affecting negatively all users, and behaves differently in different browsers when added to elements that can be shown/hidden or are moved in the DOM.
A better way to fix this may be to make the table cell (or row?) "focusable" and show these links on focus. This should also be tested on touch devices.
#13
in reply to:
↑ 12
;
follow-up:
↓ 14
@
12 years ago
Replying to adamsilverstein:
Replying to azaozz:
Tabindex is "evil" :)
It breaks the natural flow of tabbing affecting negatively all users, and behaves differently in different browsers when added to elements that can be shown/hidden or are moved in the DOM.
A better way to fix this may be to make the table cell (or row?) "focusable" and show these links on focus. This should also be tested on touch devices.
In 'normal' use I agree that tabindex is evil. However there are two values of tabindex that are actually useful - especially in answer to how you can give focus to something that isn't a link or a button.
- tabindex="0" - this includes the item in the tab order for the page, but using the context of the order that it appears in the HTML. Focus can be given to the item in javascript too.
- tabindex="-1" - Focus can be given to an item using javascript only. It does not appear in the natural tab order within a page.
These values are supported in enough modern browsers to make them safely usable.
So, you could try giving the table cells or rows tabindex values of 0. You would certainly be able to tab to the table cell/row then. Whether the table cell or row maintains meaningful focus whilst you tab around the quick links inside is another matter. I'm thinking of how you may keep the quick links panel open whilst a user interacts with with the various links and input fields. I've not tested this.
Another approach might be to use your javascript to add an extra class to the table cell or row when the post/page title receives focus. This could trigger the opening of the quick links panel. Then, whenever any of the links or elements within the quick links panel receive focus the class is pushed up through all ancestors to the tabel cell in order to keep open the quick links panel until the user tabs to a different post/page.
This all sounds much more complicated than providing a link just after the post/page title that says 'Open Quicklinks'. Clicking this will open quicklinks for that title and it will change the link to now say 'Close quicklinks'. The quicklinks panel will stay open until the user specifically closes it by clicking on that link. That way a screen reader user will onlu get all the extra items if they want them, and speech recognition users will be catered for too.
Screenshots attached.
#14
in reply to:
↑ 13
@
12 years ago
thanks for the response; so tabindex is my friend? searching core i do see their use, but will probably avoid them if i can get the tab order correct without them.
i like your idea about adding/removing a class to turn on the quicklinks, i may give that a try, i have an idea about how this could work, but i'm concerned it will not work for touch screen devices like an ipad since the cell would never become active;
if you are able to download my patch and test it, i believe it does exactly what you suggest - adding show quicklinks and hide quicklinks - 21334-2.diff. it still has some tabbing issues in firefox i need to address.
Replying to grahamarmfield:
Replying to adamsilverstein:
Replying to azaozz:
Tabindex is "evil" :)
It breaks the natural flow of tabbing affecting negatively all users, and behaves differently in different browsers when added to elements that can be shown/hidden or are moved in the DOM.
A better way to fix this may be to make the table cell (or row?) "focusable" and show these links on focus. This should also be tested on touch devices.
In 'normal' use I agree that tabindex is evil. However there are two values of tabindex that are actually useful - especially in answer to how you can give focus to something that isn't a link or a button.
- tabindex="0" - this includes the item in the tab order for the page, but using the context of the order that it appears in the HTML. Focus can be given to the item in javascript too.
- tabindex="-1" - Focus can be given to an item using javascript only. It does not appear in the natural tab order within a page.
These values are supported in enough modern browsers to make them safely usable.
So, you could try giving the table cells or rows tabindex values of 0. You would certainly be able to tab to the table cell/row then. Whether the table cell or row maintains meaningful focus whilst you tab around the quick links inside is another matter. I'm thinking of how you may keep the quick links panel open whilst a user interacts with with the various links and input fields. I've not tested this.
Another approach might be to use your javascript to add an extra class to the table cell or row when the post/page title receives focus. This could trigger the opening of the quick links panel. Then, whenever any of the links or elements within the quick links panel receive focus the class is pushed up through all ancestors to the tabel cell in order to keep open the quick links panel until the user tabs to a different post/page.
This all sounds much more complicated than providing a link just after the post/page title that says 'Open Quicklinks'. Clicking this will open quicklinks for that title and it will change the link to now say 'Close quicklinks'. The quicklinks panel will stay open until the user specifically closes it by clicking on that link. That way a screen reader user will onlu get all the extra items if they want them, and speech recognition users will be catered for too.
Screenshots attached.
#15
follow-ups:
↓ 16
↓ 17
@
12 years ago
Replying to grahamarmfield:
- tabindex="0" - this includes the item in the tab order for the page, but using the context of the order that it appears in the HTML. Focus can be given to the item in javascript too.
- tabindex="-1" - Focus can be given to an item using javascript only. It does not appear in the natural tab order within a page.
Yep, these are the only "non-evil" tabindex values :)
Having an off-screen link that would toggle a class on the table cell to show/hide the links sounds good.
We could also try moving the links off-screen (with the screen-reader-text class?) instead of hiding them. That way they will always be "visible" for screen readers. Then we can negate screen-reader-text
on hover and show them same as now.
#16
in reply to:
↑ 15
;
follow-up:
↓ 18
@
12 years ago
Replying to azaozz:
Replying to grahamarmfield:
- tabindex="0" - this includes the item in the tab order for the page, but using the context of the order that it appears in the HTML. Focus can be given to the item in javascript too.
- tabindex="-1" - Focus can be given to an item using javascript only. It does not appear in the natural tab order within a page.
Yep, these are the only "non-evil" tabindex values :)
Having an off-screen link that would toggle a class on the table cell to show/hide the links sounds good.
We could also try moving the links off-screen (with the screen-reader-text class?) instead of hiding them. That way they will always be "visible" for screen readers. Then we can negate
screen-reader-text
on hover and show them same as now.
great idea, i think i will try combining this with the show/hide approach so touch screen users can still use the links.
#17
in reply to:
↑ 15
;
follow-up:
↓ 19
@
12 years ago
Replying to azaozz:
Having an off-screen link that would toggle a class on the table cell to show/hide the links sounds good.
We could also try moving the links off-screen (with the screen-reader-text class?) instead of hiding them. That way they will always be "visible" for screen readers. Then we can negate
screen-reader-text
on hover and show them same as now.
Yes, but that doesn't help speech recognition software users who can see and who would benefit from show/hide links. Software like Dragon is not sufficiently consistent in being able to action off-screen links, and users need to know the links are there in the first place.
I know that it would not be a good idea to clutter up the pages any more than they are at the moment. So what about providing the always visible show/hide links, but make them dependent on a switch in the screen options panel. That way people can have the more verbose option if they want it, but mouse only users will be none the wiser. As a further option the quick links panel could be permanently switched on all the time as well using an option like that.
#18
in reply to:
↑ 16
@
12 years ago
actually, it looks like touch screen users are already addressed because the quicklinks show up when i tested. just have to make sure i don't break that; will try an off screen link to toggle class.
Replying to adamsilverstein:
Replying to azaozz:
Replying to grahamarmfield:
- tabindex="0" - this includes the item in the tab order for the page, but using the context of the order that it appears in the HTML. Focus can be given to the item in javascript too.
- tabindex="-1" - Focus can be given to an item using javascript only. It does not appear in the natural tab order within a page.
Yep, these are the only "non-evil" tabindex values :)
Having an off-screen link that would toggle a class on the table cell to show/hide the links sounds good.
We could also try moving the links off-screen (with the screen-reader-text class?) instead of hiding them. That way they will always be "visible" for screen readers. Then we can negate
screen-reader-text
on hover and show them same as now.
great idea, i think i will try combining this with the show/hide approach so touch screen users can still use the links.
#19
in reply to:
↑ 17
@
12 years ago
Replying to grahamarmfield:
Replying to azaozz:
Having an off-screen link that would toggle a class on the table cell to show/hide the links sounds good.
We could also try moving the links off-screen (with the screen-reader-text class?) instead of hiding them. That way they will always be "visible" for screen readers. Then we can negate
screen-reader-text
on hover and show them same as now.
Yes, but that doesn't help speech recognition software users who can see and who would benefit from show/hide links. Software like Dragon is not sufficiently consistent in being able to action off-screen links, and users need to know the links are there in the first place.
I know that it would not be a good idea to clutter up the pages any more than they are at the moment. So what about providing the always visible show/hide links, but make them dependent on a switch in the screen options panel. That way people can have the more verbose option if they want it, but mouse only users will be none the wiser. As a further option the quick links panel could be permanently switched on all the time as well using an option like that.
i like your final idea - a screen option to 'show quick links' that just turns them all on. that seems like the simplest option so far, and once you toggle that on you can use the quick links everywhere. just showing the links seems less confusing than any variation on the show/hide idea. i will give that a try.
#20
follow-up:
↓ 21
@
12 years ago
For the record, it's this sort of runaround that makes me think there really should be a specific enhanced accessibility mode for the admin.
#21
in reply to:
↑ 20
@
12 years ago
Replying to helen:
For the record, it's this sort of runaround that makes me think there really should be a specific enhanced accessibility mode for the admin.
good point! maybe the button in the screen options should say 'Enhanced Accessibility' - it could do more than turn on the quick links. almost seems like it could be a user setting instead of a screen setting.
#22
@
12 years ago
...there really should be a specific enhanced accessibility mode for the admin.
Yes, if I remember correctly this was discussed a bit some time ago. The only screen that has enhanced accessibility mode at the moment is Widgets. Perhaps there will be something similar for Menus after the UI changes there. We probably should make that option "global" and show it on all screens that have list-tables with on-hover links too.
#23
follow-up:
↓ 27
@
12 years ago
latest patch puts toggle up in screen options window just like widgets; if this is the right direction we can merge with the widget link so setting once will work across screens, maybe belongs in user settings?
#24
follow-up:
↓ 25
@
12 years ago
I derailed the spirit of this ticket, sorry :( My two cents: get the whole quick edit (and by extension, bulk edit) panel working REALLY well from an accessibility standpoint, and then we'll worry about how exactly visible links gets activated. If the first part is already done and tested, though, please correct me.
#25
in reply to:
↑ 24
@
12 years ago
Replying to helen:
I derailed the spirit of this ticket, sorry :( My two cents: get the whole quick edit (and by extension, bulk edit) panel working REALLY well from an accessibility standpoint, and then we'll worry about how exactly visible links gets activated. If the first part is already done and tested, though, please correct me.
actually, i appreciate your contribution. i think your suggestion for the 'enhanced accessibility' toggle most neatly solves the accessibility of the quick links issue raised in this ticket.
i also think we should consider a user setting for 'enhanced accessibility' mode. users needing enhanced accessibility features could be set up that way or set as such at any point from the edit user screen. pages like widgets, posts lists (and menus?) could then offer enhanced accessibility functionality. we could still let users turn mode on/off from screen options if thats helpful.
#26
@
12 years ago
Enhanced accessibility to me would be a user setting, much like a color scheme is chosen. We've talked about this several times (should it be a plugin for faster bugfixing/integrations, does it give off the sense that accessibility is a second-class citizen if we go that route, etc.). A screen option doesn't make sense once it becomes a global setting, and as much progress as we've made on screen option/help accessibility, I still find getting to them without a mouse to be awkward at best.
However, we really should get back to the issue as described in the ticket first. :)
#27
in reply to:
↑ 23
;
follow-up:
↓ 29
@
12 years ago
Replying to adamsilverstein:
latest patch puts toggle up in screen options window just like widgets; if this is the right direction we can merge with the widget link so setting once will work across screens, maybe belongs in user settings?
I strongly think we should be very cautious about assuming that if someone wants an accessibility option on one type of screen they would necessarily want it on other types of screen.
After all the accessible functionality for widgets is not the same as what is potentially being proposed here.
Accessibility options - and of course there might eventually be more than one choice - suit many different groups of people in different ways.
+1 for keeping options screen specific, although I'm happy to consider global options for each sort of screen.
#29
in reply to:
↑ 27
@
12 years ago
Replying to grahamarmfield:
Replying to adamsilverstein:
latest patch puts toggle up in screen options window just like widgets; if this is the right direction we can merge with the widget link so setting once will work across screens, maybe belongs in user settings?
I strongly think we should be very cautious about assuming that if someone wants an accessibility option on one type of screen they would necessarily want it on other types of screen.
After all the accessible functionality for widgets is not the same as what is potentially being proposed here.
Accessibility options - and of course there might eventually be more than one choice - suit many different groups of people in different ways.
+1 for keeping options screen specific, although I'm happy to consider global options for each sort of screen.
ok, thats how it works in my current patch, leaving that for consideration.
#30
follow-up:
↓ 31
@
12 years ago
Note that if always showing the row actions were to be a screen option, they exist in many places: all posts (of any type: posts, pages, attachments, custom), all terms in a taxonomy, comments, users, sites (network admin) and anything else I've missed.
In terms of this ticket/patches - have items from point 2 in the ticket description been addressed?
#31
in reply to:
↑ 30
;
follow-up:
↓ 32
@
12 years ago
Replying to helen:
Note that if always showing the row actions were to be a screen option, they exist in many places: all posts (of any type: posts, pages, attachments, custom), all terms in a taxonomy, comments, users, sites (network admin) and anything else I've missed.
In terms of this ticket/patches - have items from point 2 in the ticket description been addressed?
in terms of item 2 i was not able to reproduce the issue with tabbing/tab order. in my testing using chrome/firefox on os x i had no problems tabbing thru the date and time input fields; also, inspecting the source i was not able to find the tabindex values mentioned by the author, perhaps they were removed since the ticket was opened?
the second issue from item 2 is the lack of labels identifying the date fields. i can try to add those here in a separate patch.
#32
in reply to:
↑ 31
@
12 years ago
Replying to adamsilverstein:
also, inspecting the source i was not able to find the tabindex values mentioned by the author, perhaps they were removed since the ticket was opened?
Yes, in [21311].
#33
@
12 years ago
21334.4.diff should do the trick for the first item
Item two is no longer applicable.
#34
follow-up:
↓ 35
@
12 years ago
21334.4.diff works beautifully in chrome but fails in firefox (19.0/OS X 10.8.2). the links show up, but i am unable to navigate to them using the tab key, tabbing just takes me to the right and the links disappear. tried a few things but couldn't fix this.
#35
in reply to:
↑ 34
@
12 years ago
Replying to adamsilverstein:
21334.4.diff works beautifully in chrome but fails in firefox
Ah, nice catch. :-) 21334.5.diff should remedy that.
#36
@
12 years ago
Sorry still a few kinks to work out in 21334.5.diff. 21334.6.diff should do it.
#39
@
12 years ago
21334.diff updates 21334.6.diff against current trunk
#40
@
12 years ago
- Keywords 2nd-opinion removed
- uses focusin/out instead of focus/blur as per azaozz's comment
- tabs not spaces
#43
@
11 years ago
The focusin event is not yet supported by Firefox.
#44
@
11 years ago
Yes, there's still no native support for focusin
and focusout
in Firefox but jQuery normalizes them.
#45
@
11 years ago
refreshed as 21334.7.diff, verified works as expected in firefox with focusin/focusout
#46
@
11 years ago
Couple minor tweaks in 21334.8.diff:
- Consolidated CSS
- Removed unused "e" event
- Fixed typo "Breif" -> "brief"
Tested in MAC Chrome, FF & WIN IE8, FF, Chrome.
#51
@
11 years ago
- Owner set to helen
- Status changed from new to accepted
21334.8.diff works for me - lessbloat has indicated that my beloved Firefox is the one that needs the timeout, so going to do some more testing and then get this in.
#52
@
11 years ago
21334.9.diff fixes some spaces that should be tabs and adds the browser name that was giving us problems in the inline docs.
Currently, I can't seem to test this in firefox locally - (possibly some larger accessibility issue). when I try in firefox (24) or safari I can never even tab into the post list itself. (i'm on os x latest); tabbing works as expected in chrome. I tested in Windows8/Firefox24 with browserstack and the tabbing worked perfectly.
#53
@
11 years ago
OK, my tab key is back and it works fine locally now - turns out os x mountain lion has a feature to disable Full keyboard access that i somehow turned off (or a gremlin did it for me): see http://cl.ly/image/3w3c3A13001i & http://support.apple.com/kb/PH10711
#54
@
11 years ago
Oh, my beloved Firefox. .focusin() and .focusout() happily apply to child elements, so I simplified it in 21334.10.diff. There's also a little CSS consolidation in there, although I might handle that in a separate ticket regarding this lame .row-actions vs. .row-actions-visible thing we have going on.
#56
@
11 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
- Summary changed from Accessibility of Quick Edit panel in Posts/Pages/etc to Row actions are not always keyboard accessible
Two things:
- The original report had a few too many things collected into one ticket - I suggest opening new tickets for any specific remaining issues (such as labels for date/time input fields).
- I realized directly after committing that this fix only works for list tables that have quick edit on. Re-opening and renaming this ticket to address the rest.
#58
@
11 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
- Version 3.4.1 deleted
Been testing this in the new trunk version of WP3.8Beta1, ie with MP6 folded in, and this no longer works. Tabbing to the items in the lists does not now trigger appearance of the quick edit links.
jquery to make post list more accessible by showing quick links on post title focus