WordPress.org

Make WordPress Core

Opened 21 months ago

Closed 5 months ago

Last modified 5 months ago

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

inline-edit-post.diff (536 bytes) - added by adamsilverstein 16 months ago.
jquery to make post list more accessible by showing quick links on post title focus
wp-admin.css.diff (415 bytes) - added by adamsilverstein 16 months ago.
use opacity not visibility to show/hide quick links, keeping them accessible
wp-admin.css.2.diff (478 bytes) - added by markjaquith 14 months ago.
21334-2.diff (7.4 KB) - added by adamsilverstein 14 months ago.
add show quick links/hide quick links
open-quick-links01.jpg (30.0 KB) - added by grahamarmfield 14 months ago.
Screen shot showing open quick links links
hide-quick-links01.jpg (30.0 KB) - added by grahamarmfield 14 months ago.
Hide the quick links.
21334-3.diff (2.2 KB) - added by adamsilverstein 14 months ago.
show quick links with 'enhanced accessibility' link in screen options
21334.4.diff (1.0 KB) - added by lessbloat 14 months ago.
21334.5.diff (1.3 KB) - added by lessbloat 14 months ago.
21334.6.diff (1.4 KB) - added by lessbloat 14 months ago.
21334.diff (1.4 KB) - added by adamsilverstein 12 months ago.
update against current
21334.2.diff (1.3 KB) - added by adamsilverstein 11 months ago.
focusin/focusout; tabs not spaces
21334.3.diff (1.3 KB) - added by adamsilverstein 11 months ago.
focusin/focusout; tabs not spaces
21334.7.diff (1.4 KB) - added by adamsilverstein 9 months ago.
update against trunk, verified works w/firefox
21334.8.diff (1.3 KB) - added by lessbloat 9 months ago.
21334.9.diff (1.3 KB) - added by adamsilverstein 7 months ago.
fix spaces->tabs, slight inline doc change (name that browser)
21334.10.diff (1.4 KB) - added by helen 7 months ago.

Download all attachments as: .zip

Change History (77)

comment:1 DJPaul21 months ago

  • Cc djpaul@… added

adamsilverstein16 months ago

jquery to make post list more accessible by showing quick links on post title focus

comment:2 adamsilverstein16 months 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?

comment:3 adamsilverstein16 months 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.

adamsilverstein16 months ago

use opacity not visibility to show/hide quick links, keeping them accessible

comment:4 adamsilverstein16 months ago

  • Cc ADAMSILVERSTEIN@… added
  • Keywords 2nd-opinion has-patch added

comment:5 adamsilverstein16 months ago

this bug also affects 3.5, not sure how to indicate that in trac, version dropdown ends at 3.4.1

comment:6 SergeyBiryukov15 months ago

  • Milestone changed from Awaiting Review to 3.6

comment:7 follow-up: markjaquith14 months ago

Just refreshed it to be patched from the root.

comment:8 in reply to: ↑ 7 ; follow-up: adamsilverstein14 months 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?

comment:9 in reply to: ↑ 8 ; follow-up: grahamarmfield14 months 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.

comment:10 in reply to: ↑ 9 adamsilverstein14 months 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.

adamsilverstein14 months ago

add show quick links/hide quick links

comment:11 follow-up: azaozz14 months 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.

Last edited 14 months ago by azaozz (previous) (diff)

comment:12 in reply to: ↑ 11 ; follow-up: adamsilverstein14 months 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:

  1. show quick links at all times, remove hover on/off code - i like this the best personally
  2. use current method - show/hide quicklinks (but with no tabindex and more browser testing for tab layout); also keeps existing hover on/off effect
  3. 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.

comment:13 in reply to: ↑ 12 ; follow-up: grahamarmfield14 months 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.

grahamarmfield14 months ago

Screen shot showing open quick links links

grahamarmfield14 months ago

Hide the quick links.

comment:14 in reply to: ↑ 13 adamsilverstein14 months 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.

comment:15 follow-ups: azaozz14 months 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.

comment:16 in reply to: ↑ 15 ; follow-up: adamsilverstein14 months 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.

comment:17 in reply to: ↑ 15 ; follow-up: grahamarmfield14 months 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.

comment:18 in reply to: ↑ 16 adamsilverstein14 months 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.

Last edited 14 months ago by adamsilverstein (previous) (diff)

comment:19 in reply to: ↑ 17 adamsilverstein14 months 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.

comment:20 follow-up: helen14 months 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.

comment:21 in reply to: ↑ 20 adamsilverstein14 months 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.

Last edited 14 months ago by adamsilverstein (previous) (diff)

comment:22 azaozz14 months 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.

adamsilverstein14 months ago

show quick links with 'enhanced accessibility' link in screen options

comment:23 follow-up: adamsilverstein14 months 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?

comment:24 follow-up: helen14 months 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.

comment:25 in reply to: ↑ 24 adamsilverstein14 months 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.

comment:26 helen14 months 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. :)

comment:27 in reply to: ↑ 23 ; follow-up: grahamarmfield14 months 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.

comment:28 toscho14 months ago

  • Cc info@… added

comment:29 in reply to: ↑ 27 adamsilverstein14 months 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.

comment:30 follow-up: helen14 months 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?

comment:31 in reply to: ↑ 30 ; follow-up: adamsilverstein14 months 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.

comment:32 in reply to: ↑ 31 SergeyBiryukov14 months 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].

lessbloat14 months ago

comment:33 lessbloat14 months ago

21334.4.diff​ should do the trick for the first item

Item two is no longer applicable.

Last edited 14 months ago by lessbloat (previous) (diff)

comment:34 follow-up: adamsilverstein14 months 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.

comment:35 in reply to: ↑ 34 lessbloat14 months ago

Replying to adamsilverstein:

21334.4.diff works beautifully in chrome but fails in firefox

Ah, nice catch. :-) 21334.5.diff​ should remedy that.

lessbloat14 months ago

lessbloat14 months ago

comment:36 lessbloat14 months ago

Sorry still a few kinks to work out in 21334.5.diff​. 21334.6.diff​ should do it.

comment:37 adamsilverstein14 months ago

verified 21334.6.diff​ works correctly in firefox, nice!

comment:38 azaozz14 months ago

Wondering if we can use focusin and focusout to do this.

adamsilverstein12 months ago

update against current

comment:39 adamsilverstein12 months ago

21334.diff​ updates 21334.6.diff against current trunk

adamsilverstein11 months ago

focusin/focusout; tabs not spaces

adamsilverstein11 months ago

focusin/focusout; tabs not spaces

comment:40 adamsilverstein11 months ago

  • Keywords 2nd-opinion removed

21334.3.diff​

comment:41 ocean9010 months ago

  • Keywords 3.7-early added
  • Milestone changed from 3.6 to Future Release

comment:42 wonderboymusic9 months ago

  • Milestone changed from Future Release to 3.7

these are all marked 3.7-early

comment:44 azaozz9 months ago

Yes, there's still no native support for focusin and focusout in Firefox but jQuery adds them.

Last edited 9 months ago by azaozz (previous) (diff)

adamsilverstein9 months ago

update against trunk, verified works w/firefox

comment:45 adamsilverstein9 months ago

refreshed as 21334.7.diff, verified works as expected in firefox with focusin/focusout

lessbloat9 months ago

comment:46 lessbloat9 months 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.

Last edited 9 months ago by lessbloat (previous) (diff)

comment:47 togelini8 months ago

Nothing.

Last edited 8 months ago by ocean90 (previous) (diff)

comment:48 togelini8 months ago

Nothing.

Last edited 8 months ago by ocean90 (previous) (diff)

comment:49 togelini8 months ago

Nothing.

Last edited 8 months ago by ocean90 (previous) (diff)

comment:50 togelini8 months ago

Nothing.

Last edited 8 months ago by ocean90 (previous) (diff)

comment:51 helen7 months 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.

adamsilverstein7 months ago

fix spaces->tabs, slight inline doc change (name that browser)

comment:52 adamsilverstein7 months 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.

Last edited 7 months ago by adamsilverstein (previous) (diff)

comment:53 adamsilverstein7 months 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

helen7 months ago

comment:54 helen7 months 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.

comment:55 helen7 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 25593:

Allow non-visible post row actions to be accessed via keyboard. props adamsilverstein, lessbloat. fixes #21334.

comment:56 helen7 months 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:

  1. 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).
  2. 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.

comment:57 helen7 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 25595:

Allow all non-visible default row actions in the admin to be accessed via keyboard. fixes #21334.

comment:58 grahamarmfield5 months 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.

comment:59 helen5 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

Please open a new ticket - this was closed on a completed milestone.

Note: See TracTickets for help on using tickets.