Make WordPress Core

Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#25100 closed defect (bug) (fixed)

Initial focus on the Add Media panel

Reported by: johnbillion's profile johnbillion Owned by: helen's profile helen
Milestone: 4.0 Priority: normal
Severity: normal Version: 3.5
Component: Media Keywords: needs-patch
Focuses: accessibility Cc:

Description

Splitting this out from #23561

Screenreader: NVDA 2012.2.1
Browsers: IE9 and FF16.0.2 on Windows 7

When opening the Add Media panel from the post editing screen it's not clear to users of screenreaders (or to sighted users using keyboard navigation) where the keyboard focus is.

IE9

  • On initially clicking Add Media link in Edit Post page the focus appears to initially be transferred into the edit content textarea within the main page. There is no audible notification that the panel has opened.
  • Further tabbing shows that the focus has not been transferred into the panel - so this would be a showstopper for most users.

If you continue tabbing you eventually do come to the panel in the tab order at the bottom of the main page maybe...

Firefox

  • When the Add Media panel opens it is not clear where focus sits. But after this first link the focus is transferred into the Add Media panel.

Change History (18)

#1 @r0uter
11 years ago

  • Cc 01tonythomas@… added

#2 @r0uter
11 years ago

  • Cc 01tonythomas@… removed

#3 @grahamarmfield
11 years ago

Can confirm that this issue is also the case in IE10 running on a Windows 7 laptop. Focus is not transferred into the Add Media panel.

#4 follow-up: @sharonaustin
11 years ago

  • Cc sharon.austin.2014@… added

So is JQuery a realistic answer here? I'd appreciate feedback before giving this a shot. I see a possibility for a patch based on the format of the code below, swapping out the alert for an appropriate focus. (The source of the example below is found here: http://stackoverflow.com/questions/7465006/differentiate-between-mouse-and-keyboard-triggering-onclick)

jQuery(function($) {

$("a#foo").keydown(function() {

alert("keyboard");
return false;

}).click(function() {

alert("mouse");
return false;

})

})

Version 0, edited 11 years ago by sharonaustin (next)

#5 in reply to: ↑ 4 ; follow-up: @GrahamArmfield
11 years ago

  • Cc graham.armfield@… added

Replying to sharonaustin:

So is JQuery a realistic answer here?

I haven't really looked at the underlying code that opens the modal, but there must be a routine somewhere that does that. I'm assuming it would be in jQuery but I'm not certain.

I would imagine that all you need then is an extra command at the end of that function to move the keyboard focus into the modal. Unfortunately I don't know enough about jQuery to know how to do that.

The different behaviour between the browsers is an interesting challenge - and I've noticed the behaviour myself. Presumably there must be some branching for different browsers, or extra stuff that needs to be done for certain browsers.

#6 in reply to: ↑ 5 ; follow-up: @sharonaustin
11 years ago

Replying to GrahamArmfield:

Thank you, Graham, I appreciate that. I had been looking at trying to somehow incorporate tabindex="0" etc. but I thought I came across a piece of information that certain browsers do not interpret the tabindex feature. I'll try to find a definitive source where I picked up that piece of information, but it was for that reason I started looking at JQuery. My main concern with JQuery is that, as I understand it, JQuery is always relying on "external" libraries---what if we make the patch and it "works", but then the external JQuery libraries are updated? Wouldn't that mean that the patch would also stop working? (Asking out of total ignorance here)

#7 follow-up: @helen
11 years ago

Yes, there's a small possibility that updating jQuery will break existing JavaScript, but the same is true across the admin. Ideally we would have testing set up for this, but we don't (yet). If the JS is solid and sane (we can iterate on patches here, don't feel stressed about getting it perfect the first time), it should hold up. Also, since the media modal is JS-only, you are fine to use it to transfer focus, etc. as you need.

#8 in reply to: ↑ 7 @sharonaustin
11 years ago

Replying to helen:
Thank you, Helen, that piece of information is much appreciated.

#9 in reply to: ↑ 6 @sharonaustin
11 years ago

Replying to sharonaustin:

Replying to GrahamArmfield:

Thank you, Graham, I appreciate that. I had been looking at trying to somehow incorporate tabindex="0" etc. but I thought I came across a piece of information that certain browsers do not interpret the tabindex feature. I'll try to find a definitive source where I picked up that piece of information...

Just FYI, here's a few links I found that gave rise to the concern about using tabindex and certain browsers not "respecting" the code. The problem, *IF* it exists for modern browsers, seems to be with Opera and Safari (and certain references to skip-links in Chrome). I've seen just as many claims that there are no problems using tabindex with any modern browsers. But, it might be a good idea to specifically request testing with those browsers when we have patches that use tabindex="0". I'll try and dig up a Mac somewhere when we test.

http://stackoverflow.com/questions/2292016/is-there-a-workaround-to-safaris-operas-bug-that-you-cant-tab-through-hyperli


http://html.cita.illinois.edu/nav/form/text/index.php?example=11


http://webaim.org/discussion/mail_message?id=17629

#10 @nacin
11 years ago

  • Component changed from Accessibility to Media
  • Focuses accessibility added

This ticket was mentioned in IRC in #wordpress-ui by davidakennedy. View the logs.


11 years ago

#12 follow-up: @helen
11 years ago

  • Milestone changed from Awaiting Review to 4.0

Working on overall keyboard accessibility in #23560 - focus is transferred now, can this be re-evaluated and see what more should be done here?

#13 in reply to: ↑ 12 ; follow-up: @sharonaustin
10 years ago

Replying to helen:

Working on overall keyboard accessibility in #23560 - focus is transferred now, can this be re-evaluated and see what more should be done here?

Hi Helen, when opening the Add Media panel from the post editing screen, if one tabs through to the post editing screen, it is now clear where the keyboard focus is, so this is a huge improvement--huge thanks to you and the other developers.

One problem that seems to be remaining is that when it comes to the specific case of the buttons under the title link, the "Change Permalinks", the "View Post" and the "Add Media" button, the focus for the button remains hard to distinguish (mouse users--hover) or non-functional (keyboard) for these three buttons.

In the case of using the mouse: Hovering over the "Add Media" button gives a "darker" outline to the button, but the outline is still very thin and hard to see, and it is different than the blue glow outline used elsewhere on the page, so that would mean a user might miss the fact that he/she is actually at the right location. I am unable to get to the "Add Media" button using a keyboard.

This happens to also be true of the "Change Permalinks" and "View Post" buttons.

This was true of all three browsers, using 4.0-alpha-20140701.
Chrome, Version 35.0.1916.153 m
The same also for Firefox version 30.0,
and IE version 10.0.9200.16921

#14 @sharonaustin
10 years ago

Sorry, a little more information here...I'm able to tab to the "Change Permalinks" and "View Post" "buttons" if I tab backwards....but not forwards.

This ticket was mentioned in IRC in #wordpress-ui by _Redd. View the logs.


10 years ago

#16 @sharonaustin
10 years ago

My mistake, apparently I misunderstood the intention of the ticket. (See conversation from Wednesday's accessibility chat meeting July 9). Please disregard above. Another, separate ticket should be opened on the above comments I made. Thanks.

#17 @helen
10 years ago

  • Owner set to helen
  • Resolution set to fixed
  • Status changed from new to closed

In 29220:

Keyboard accessibility for the media modal:

  • Arrow keys navigate between items in the grid.
  • Transfer focus into the panel when selecting a tab along the side.
  • Transfer focus into the details sidebar when selecting an item and vice versa.
  • Set initial focus on the close button so that it is visible.

props celloexpressions, lessbloat, ericlewis. fixes #25100, #25101, #28704. see #23560.

#18 in reply to: ↑ 13 @SergeyBiryukov
10 years ago

Replying to sharonaustin:

One problem that seems to be remaining is that when it comes to the specific case of the buttons under the title link, the "Change Permalinks", the "View Post" and the "Add Media" button, the focus for the button remains hard to distinguish (mouse users--hover) or non-functional (keyboard) for these three buttons.

Related: #28267

Note: See TracTickets for help on using tickets.