Keyboard focus in the theme customizer should be on left options panel

[pjad]

For accessibility reasons, users should be able to tab through the options in the theme customizer. Currently when you open the customizer at /wp-admin/customize.php focus appears to be behind the view and it's not clear how you can tab to the options.

[helenyhou]

Ran into this myself this other day. Extremely frustrating and completely inaccessible. Moving to 3.5 to see how we can actively address it.

[grahamarmfield]

Perhaps I can suggest the way this should work to be accessible to users who can't/don't use a mouse. Quite happy to debate it.

The user is on the Appearance -> Themes page and they tab to and action the Customize link. (Ideally this link should indicate that new panel will open).

As the panel for theme customization opens the focus should be moved into the panel - maybe onto the Close button but Saved is OK. But alternatively you could put a heading of 'Customization Options' at the top and make that the destination item of the in-page link. That might work better for screen readers as it reassures those users that they're in the right place.

It should obviously be possible to tab to each of the option groupings and toggle them open and shut and make it obvious how to do that. When focus lands on each item it needs to voice what it is (in a screen reader) and show it has focus. The individual items in each grouping need to be able to get focus and show visibly that they have got focus. All the individual items need to be able to be keyboard operated - the colour pickers have accompanying text boxes which is good but they have no labels. But the selection of the background images may need rethinking to make that keyboard operable.

I'd recommend repeating the Save and Publish button at the bottom of all the groupings. It's a more logical place for those tabbing using keyboards to see it/find it.

When the user clicks on the Close button and the panel shuts the focus must be transferred back to somewhere useful - suggest the Customize button that launched the whole thing in the first place.

If focus is to be kept within the customiser panel until user explicitly shuts it that's OK. But is focus could 'bleed' back onto the underlying Appearance screen then this should be spotted and the panel closed and focus put back to the Customize button.

As a nice to have, help text would be really useful in this whole area. I can see and work out what's going on but not all site admins will necessary get how to use this really useful functionality.

[nacin]

Replying to grahamarmfield:

Perhaps I can suggest the way this should work to be accessible to users who can't/don't use a mouse. Quite happy to debate it.

Thank you for this!

[helenyhou]

Would having a keyboard shortcut of ctrl/cmd-s to save and publish and using esc to cancel be an acceptable alternative to repeating the buttons per section? Just brainstorming a bit.

[grahamarmfield]

Replying to helenyhou:

Would having a keyboard shortcut of ctrl/cmd-s to save and publish and using esc to cancel be an acceptable alternative to repeating the buttons per section? Just brainstorming a bit.

helenyhou I hadn't imagined having a button for each section - just repeating the close and save buttons at the bottom of all the groups of options.

The issue with keyboard shortcuts is threefold (in my view):

1) Discoverability - How do you let people know what they are? There would always need to be some findable instructions somewhere about that. And they would need to visible too - I'm thinking of sighted keyboard users, those with cognitive impairments etc

2) Consistency. Are similar keyboard shortcodes used in other places within the WordPress admin? If keystrokes are different in each block of functionality then we'd end up with a real confusing mess.

3) Hijacking keyboard shortcodes from assistive technology (AT). There are many forms of assistive technology out there - screen readers being the most well know example but by no means the only example. Each piece of AT will have it's own control mechanisms, which in the case of screen readers is a huge suite of keyboard shortcuts. If websites/apps use keystroke combinations that clash with those used by some AT then these sites can effectively take away key functionality of the AT.

For that reason my own recommendation would be to not employ keystrokes here.

The options in the various groupings - Site Title, Colors, Layout etc do persist when you move to another group so I think it would be OK for there to be just one button for save and publish, or a repeated one at the bottom too - as Custom Menu builder which would fall nicely under a forward tabbing user rather than them having to go right back up to the top again.

Opening the panel for each group with the enter key is acceptable - that's like Custom Menu too, although of course the Custom Menu area has it's own share of accessibility problems - see #21289

From what I'm seeing, the biggest challenge in this area is to get everything to meaningfully accept focus, show it, and allow screen readers to voice what it's for, and then to accept choosing by keyboard. Some clear instructions at the top would be nice too.

[esmi]

For that reason my own recommendation would be to not employ keystrokes here.

Loudly seconded! The last time a group of us looked at what keys were available once you removed all AP software keys and took multiple languages into account, there were only about 3 keys left apart from the numerics. Use anything apart from 0-9 and you will hijack someone's AT. Ten numbers don't exactly leave you a lot to play with given that you also need to use them consistently right across the board.

Some clear instructions at the top would be nice too.

Could the Screen Options pane be used here?

[lessbloat]

21283.diff is a first pass at this. It's a bit hacky.

Notes:

• The "close" button is blue on focus - this is fixed in #21598.
• The color pickers don't pick up focus - this is fixed in #21206.

Let me know if you notice anything else.

[lessbloat]

In 21283.2.diff I added the ability to focus on the the custom image selector element, and the tabs within that area.

Image thumbnails, and the "select a file" link need keydown (enter) events added in addition to click events.

[helenyhou]

Patch actually works quite well for me, although it does highlight the need for the cancel/save buttons to be repeated at the bottom (shift-tabbing back up is a huge pain). I'm also not sure it's the greatest idea to have each section just pop open on focus rather than having to trigger it to open, especially if that section contains many options that then have to be tabbed through to get to the next section.

[lessbloat]

Replying to helenyhou:

Patch actually works quite well for me,

You sound surprised... ;-)

I'm also not sure it's the greatest idea to have each section just pop open on focus rather >than having to trigger it to open, especially if that section contains many options that then >have to be tabbed through to get to the next section.

Changed in 21283.3.diff

[helenyhou]

Definitely feels better with triggering to open a section. Just noticed (probably existed in previous patch): once the Save & Publish button becomes active after making a change, if you tab to it, you can't tab back out of it. Tried in both FF and Chrome (OSX).

[lessbloat]

Changes in 21283.4.diff:

• Includes changes in 21283.3.diff
• Adds cancel/save buttons at the bottom in addition to the top
• Fixed "once the Save & Publish button becomes active after making a change, if you tab to it, you can't tab back out of it"

[lessbloat]

Remaining issues that I'm aware of:

1) tabbing is missing from color picker (this should be fixed in #21206, as it should work anywhere the color picker is displayed, not just in the customizer). Fixed in #​http://core.trac.wordpress.org/ticket/21206#comment:69

2) Image thumbnails, and the "select a file" link need keydown (enter) events added in addition to click events. I'll need @koopersmith to take a look at these.

[grahamarmfield]

Replying to lessbloat:

Changes in 21283.4.diff:

• Includes changes in 21283.3.diff
• Adds cancel/save buttons at the bottom in addition to the top
• Fixed "once the Save & Publish button becomes active after making a change, if you tab to it, you can't tab back out of it"

Appreciate all the work that's being done here, but there is one key piece that is still missing - how to get into the theme customizer panel without using a mouse.

I've downloaded the latest nightly and I can tab everywhere quickly and easily using the new Skip links and clearly visible focus. Within the Appearance -> Themes page I can tab to the customize link and action it with a keystroke, but where is the focus now? It certainly doesn't seem to be in the theme customizer panel.

[lessbloat]

Replying to grahamarmfield:

one key piece that is still missing - how to get into the theme customizer panel without using a mouse.

Nice catch @grahamarmfield. 21283.5.diff should fix that.

[helenyhou]

Replying to grahamarmfield:

Appreciate all the work that's being done here, but there is one key piece that is still missing - how to get into the theme customizer panel without using a mouse.

This patch hasn't been committed because it's still in progress, so you won't get it in the latest nightly. With lessbloat's latest patch applied (SVN talk), the focus is indeed inside the customizer, specifically on the Close button, and you can tab from there.

[21283.5.diff] feels quite nice to me. Not sure how to feel about the visible repetition of the buttons at the bottom - might be something for Koop to weigh in on. There's a funny moment if you tab early (I think before load completes) where it will jump focus back to the close button. Only other real thing I noticed - the collapse toggle doesn't work, although it can be tabbed to.

[grahamarmfield]

Replying to helenyhou:

This patch hasn't been committed because it's still in progress, so you won't get it in the latest nightly. With lessbloat's latest patch applied (SVN talk), the focus is indeed inside the customizer, specifically on the Close button, and you can tab from there.

Thanks - I'll look out for that.

[21283.5.diff] feels quite nice to me. Not sure how to feel about the visible repetition of the buttons at the bottom - might be something for Koop to weigh in on. There's a funny moment if you tab early (I think before load completes) where it will jump focus back to the close button. Only other real thing I noticed - the collapse toggle doesn't work, although it can be tabbed to.

From my perspective repeating the buttons visible at the bottom is a good idea (even though I haven't seen it yet). It echoes functionality in other parts of the admin screens. Also, keyboard accessibility is not just for those with poor sight - it's for sighted individuals who can't or have difficulty using a mouse. To have to tab all the way back up to the top is not great usability. If you really can't have them repeated visibly then it might be desirable to just have them at the bottom and not at the top.

Also, focus arriving on a Close button... this troubles me slightly - especially as the alternate text for the close button just says 'Close'. Would people using a screen reader get enough context there? Could there not be a Heading at the top of the panel that says 'Theme Customizer Options' that could get the focus?

[lessbloat]

Replying to helenyhou:

There's a funny moment if you tab early (I think before load completes) where it will jump focus back to the close button

Should be fixed in 21283.6.diff

Only other real thing I noticed - the collapse toggle doesn't work, although it can be tabbed to.

fixed in 21283.6.diff (and added a bit stronger box-shadow).

Not sure how to feel about the visible repetition of the buttons at the bottom

Replying to grahamarmfield:

Also, focus arriving on a Close button... this troubles me slightly - especially as the alternate text for the close button just says 'Close'. Would people using a screen reader get enough context there? Could there not be a Heading at the top of the panel that says 'Theme Customizer Options' that could get the focus?

In 21283.6.diff I also removed the top buttons, and on page load, forced focus on the "You are previewing" div (and added aria-label="Theme Customizer Options" to that div). Here's what it looks like now:

[grahamarmfield]

Replying to lessbloat:

In 21283.6.diff I also removed the top buttons, and on page load, forced focus on the "You are previewing" div (and added aria-label="Theme Customizer Options" to that div). Here's what it looks like now:

Nice one - can't wait to try that out.

[SergeyBiryukov]

Related: #22237

[jorbin]

I tested this in safari with voiceover and in IE8 (no screen reader). Everyone works exactly as expected. It's generally easy to navigate around and I think it's ready to go it and get some broader testing.

[jorbin]

Replying to lessbloat:

2) Image thumbnails, and the "select a file" link need keydown (enter) events added in addition to click events. I'll need @koopersmith to take a look at these.

After some additional testing I ran into these as well but missed them when I was reading the ticket. Selecting a thumbnail is fixed in my updated patch. I have no idea how the upload code works, so that still remains open.

[helenyhou]

Selecting a thumbnail works well for me in 21283.7.diff​. Could we possibly get a version of that without moving the save/close buttons to the bottom? It is something that we need to address somehow, but if we're going to propose that we get an in-progress commit in, I'd rather not move that entirely just yet, especially because it looks kind of bad.

[SergeyBiryukov]

In 21283.7.diff​, line 384 of customize-controls.js looks like a typo.

[jorbin]

no one ever accused me of knowing how to type

[lessbloat]

Replying to helenyhou:

Could we possibly get a version of that without moving the save/close buttons to the bottom?

Buttons moved back to the top in 21283.9.diff.

[grahamarmfield]

Replying to lessbloat:

Replying to helenyhou:

Could we possibly get a version of that without moving the save/close buttons to the bottom?

Buttons moved back to the top in 21283.9.diff.

Placing buttons at the bottom of the update panels in the Theme Customizer just sounds to me like a sensible thing to do from a usability as well as accessibility point of view. Whilst those people using a mouse will click on buttons wherever they are (up to a point), those who rely on keystrokes need to tab to the buttons. Aren't we asking a lot for keyboard users to have made all their changes and to then have to shift-tab all the way back up to the top again to save their changes?

Most forms out there on the internet have the submit buttons at the bottom of the form for a good reason - that it is the logical next step when you've added the information asked for.

helenyhou it may seem strange to see them at the bottom but is that just because it's different to what's there now? Surely greater ease of use is more important here. lessbloat has shown that with his excellent user tests.

[helenyhou]

Replying to grahamarmfield:

Please understand that I am asking that an interim commit not include a visual change that is not polished. Nothing has been committed yet in any case - I only asked for a version of the patch that did not move those buttons. I agree that there needs to be some kind of solution for the save and cancel buttons, but just moving them while neglecting the visual/UI is not the right path either. We can make these changes in multiple steps - I think the more important part is to make the customizer work at all and get that committed so that those who are not versed in SVN and applying patches, which is certainly the majority of people, can actually start testing.

[grahamarmfield]

Replying to helenyhou:

OK that's good, thanks for clarifying - I guess I'm still learning about the process that's being followed here. I'm unsure when is the right time to express my views on things like this - didn't want to wait until it was too late.

[nacin]

Quick review:

• "accordian" -> "accordion"

• aria-label="Theme Customizer Options" needs to be translatable

• Not sure why #save needs to become .save

[lessbloat]

Replying to nacin:

• Not sure why #save needs to become .save

Yep, only needs to be if we have buttons at the top and at the bottom.

[JustinSainton]

Patch with nacin's suggestions

[nacin]

In 22400:

Keyboard accessibility for the theme customizer. props lessbloat, jorbin, JustinSainton. fixes #21283.

[grahamarmfield]

Replying to nacin:

In 22400:

Keyboard accessibility for the theme customizer. props lessbloat, jorbin, JustinSainton. fixes #21283.

Noting that this has been closed as fixed before debate has been had about positioning of the Save and Close buttons.

The options are:

• Leave positioning as now - ie at the top
• Move buttons to bottom of Customizer 'sidebar'
• Have two sets of buttons - at the top and the bottom

From a usability and accessibility perspective I certainly favour the second or the third. If current status quo maintained then keyboard users (inc screen reader users) will need to reverse tab up through all the bits to get back to the Save button.

When will I be able to see the 'finished' Theme Customizer and test for accessibility? I'm downloading the nightly builds but I'm guessing it's not in there yet?

[nacin]

Replying to grahamarmfield:

If current status quo maintained then keyboard users (inc screen reader users) will need to reverse tab up through all the bits to get back to the Save button.

How is this different from, say, a single Publish or Save button on the posts screen? The customizer automatically offers a live preview with every change, while "Save" actually commits the changes. Tabbing around is not unusual when submitting a form. Not to mention, users who use only the keyboard are more likely to use additional tools to allow for quicker navigation (Dragon NaturallySpeaking as probably the pre-eminent example). Eventually, tabbing will return to the top anyway.

When will I be able to see the 'finished' Theme Customizer and test for accessibility? I'm downloading the nightly builds but I'm guessing it's not in there yet?

It will be in today's nightly build.

[nacin]

Re-opening this for a few style things I am noticing.

1. The section headers end up with big blue focus styles in addition to the dark gray, which is overload. Hiding the blue focus style seems good.

2. Is there a need to give the "You are previewing" section the dark gray? In this case, the blue focus style seems sufficient.

3. Some footer-related CSS snuck into [22400].

[grahamarmfield]

Replying to nacin:

How is this different from, say, a single Publish or Save button on the posts screen? The customizer automatically offers a live preview with every change, while "Save" actually commits the changes. Tabbing around is not unusual when submitting a form. Not to mention, users who use only the keyboard are more likely to use additional tools to allow for quicker navigation (Dragon NaturallySpeaking as probably the pre-eminent example). Eventually, tabbing will return to the top anyway.

You are of course right that other screens involve a fair bit of tabbing around to allow visiting all the necessary inputs etc that need attention. My thoughts were simply on ease of use. To me it seems intuitive to put buttons at the bottom of a series of input fields. But having the buttons at the top is better than the whole thing not being accessible. Don't get me wrong, I'm really pleased that the Theme Customizer has received the attention it has got for this release and I'm looking forward to trying it out - and yes (taking your point) in Dragon Naturally Speaking too as well as with NVDA.

It would be interesting for Lessbloat to do some video tests with users of AT in addition to the other ones.

It will be in today's nightly build.

Great, thanks.

[lessbloat]

Replying to nacin:

Re-opening this for a few style things I am noticing.

1. The section headers end up with big blue focus styles in addition to the dark gray, which is overload. Hiding the blue focus style seems good.

Done in 21283.11.patch.

2. Is there a need to give the "You are previewing" section the dark gray? In this case, the blue focus style seems sufficient.

The blue focus style is not shown in all browsers (notably FF). We could take a stab at making this grey lighter if you think it's too overbearing.

3. Some footer-related CSS snuck into [22400].

Removed them.

[toscho]

Replying to grahamarmfield:

The options are:

• Leave positioning as now - ie at the top

Great, as long as the home/Pos1 button works.

• Move buttons to bottom of Customizer 'sidebar'
• Have two sets of buttons - at the top and the bottom

From a usability and accessibility perspective I certainly favour the second or the third. If current status quo maintained then keyboard users (inc screen reader users) will need to reverse tab up through all the bits to get back to the Save button.

Why? As a keyboard user I have no problem hitting home. But having more tab stations is often rather annoying (that’s why I preferred the old admin menu).

When will I be able to see the 'finished' Theme Customizer and test for accessibility? I'm downloading the nightly builds but I'm guessing it's not in there yet?

This takes some time, the Nightly is rebuild just once per day. I’m waiting for that too. :)

[helenyhou]

21283.10.diff​ makes the focus styles more closely match that of hover.

[nacin]

In 22452:

Customizer accessibility: Align focus styles with hover styles. props helenyhou. fixes #21283.

[nacin]

In 22453:

Don't show additional focus outline on customizer sections. Remove unused CSS selectors. props lessbloat. see #21283.

[koopersmith]

In 22491:

Pinking shears. see #21283.

[koopersmith]

I'm encountering some buggy collapsing/reopening.

1. Expand the background image section.
2. Expand the background image control so that the dropzone is visible.
3. Switch away from the window to locate a file (with the intent to drag/drop).
4. The background image control closes, hiding the dropzone.

[lessbloat]

Replying to koopersmith:

I'm encountering some buggy collapsing/reopening.

21283.12.diff is a quick attempt at fixing this.

[nacin]

In 22512:

Customizer: Passes focus to the upload tab to avoid focus changing when a drag event occurs from outside the browser. props lessbloat. fixes #21283.

[koopersmith]

Still buggy.

1. Click two accordion labels in rapid succession.
2. The first label clicked will open and remain stuck open.
3. The second label will be focused.

[lessbloat]

Replying to koopersmith:

Still buggy.

1. Click two accordion labels in rapid succession.
2. The first label clicked will open and remain stuck open.
3. The second label will be focused.

Should be fixed in 21283.13.diff​.

[nacin]

In 22563:

Revert accordion-delay code from [22400] that was causing problems. props lessbloat. fixes #21283.

[grahamarmfield]

Am testing this functionality using the keyboard only and it is impressive what is now possible. There are some small issues however:

1. I can tab to the sliders for selecting the Background Colours but I am unable to influence the first one (the colour) using the keyboard. The arrow keys don't appear to do anything. It is possible to influence the second slider, although the default position at the bottom of the track means the functionality of the main colour slider is not obvious.
2. Also, in Background Colours, it is not possible to tab to any of the colour blocks beneath the first slider - yet they are clickable.
3. Interacting with the header image - I can successfully tab through the images and select one by pressing the enter key. However it appears to be then impossible to re-select the default image. I can tab to the Default link but pressing Enter doesn't appear to do anything.
4. When I open the Background Image panel, the first tab onwards takes me to a link that is 'Upload New'. Using Enter on this link doesn't do anything. Next tab forward takes me to 'select a file' link. Actioning this with a keyboard doesn't do anything either. Tabbing on from 'select a file' takes me to an invisible link or item - that also cannot be actioned. I was expecting to be at Static Front Page.
5. In Static Front Page the first tab stop is the radio button group. There is no visible focus on the radio buttons. (Suggest also that the labels are amplified for screen reader users to explain what's happening - the labels voice "Your latest posts" without the context of 'Front page displays'.)
6. The next tab stop is Collapse - this link doesn't appear to do anything when actioned with keyboard - probably just as well as I haven't saved yet.
7. When I've saved the options and have actioned the close button, I'd expect focus to be returned to the Customize link where I opened the Theme Customizer from in the first place. In fact it's at the very top of the page.

Hope this helps.

[kovshenin]

Sorry for the .patch vs .diff confusion, mine got to be .11 although it's actually somewhere around .14 :)

In 21283.11.diff​:

• Handle space/return hits on the default button in the color picker
• Add tabindex to the color palette and have them handle space/return keys

Hope this helps :)

[grahamarmfield]

Testing the Theme Customizer using Dragon Naturally Speaking 12 - with Firefox 12 and IE9 on Windows 7 machine:

Firefox
It's possible to navigate with Dragon to most places in the WP admin - including the Themes page. Then I can say "Click Customize" and I'm into the Theme Customizer. Unfortunately using spoken commands won't achieve much after that - it seems that Dragon is not really conscious of the opened panel. All commands such as "Click Header Image" which should open the Header Image panel yield either nothing, or unexpected results. It is possible to use the move mouse commands in Dragon as well as the mouse grid, but this is quite laborious when you'd expect the normal speech commends to work.

One unfortunate by-product of having a button labelled Close is that when the Dragon user says "Click Close" that is the default command to close the browser window, and that is what happens.

IE9
The same situation as with Firefox. Dragon is obviously still conscious of all the links beneath the panel as stating "Click Header Image" actually closes the Customizer and takes user to Custom Header page under Appearance.

I'm afraid I'm not an expert in how Dragon works so I've no insight into why it doesn't recognise the clickable H3s - perhaps because they are not actually links maybe? Once the panels are open it also doesn't recognise the labels for the controls either. That might be down to the implicit linking of the labels with the input fields rather than explicit.

[helenyhou]

Replying to kovshenin:

In 21283.11.diff​:

• Handle space/return hits on the default button in the color picker
• Add tabindex to the color palette and have them handle space/return keys

Maybe that would be better over on #22475? Since it's not specific to the customizer.

[SergeyBiryukov]

[22400] removed box-shadow for .wp-full-overlay-header. Was that intentional?

The thin white line now seems inconsistent with the rest of UI: 21283.header-no-box-shadow.png​.

[lessbloat]

Replying to grahamarmfield:

Am testing this functionality using the keyboard only and it is impressive what is now possible. There are some small issues however:

1. I can tab to the sliders for selecting the Background Colours but I am unable to influence the first one (the colour) using the keyboard. The arrow keys don't appear to do anything. It is possible to influence the second slider, although the default position at the bottom of the track means the functionality of the main colour slider is not obvious.

Nice catch. There is a separate ticket for this now: #22475.

2. Also, in Background Colours, it is not possible to tab to any of the colour blocks beneath the first slider - yet they are clickable.

​21283.11.diff fixes this.

3. Interacting with the header image - I can successfully tab through the images and select one by pressing the enter key. However it appears to be then impossible to re-select the default image. I can tab to the Default link but pressing Enter doesn't appear to do anything.

Are your referring to the "default" tab just above the images? If so, that is just a tab, not a link. It does look kind of odd to have a single tab there, but if you've uploaded an image (through Appearance) another (uploaded) tab appears before it.

5. In Static Front Page the first tab stop is the radio button group. There is no visible focus on the radio buttons. (Suggest also that the labels are amplified for screen reader users to explain what's happening - the labels voice "Your latest posts" without the context of 'Front page displays'.)

This section needs to be updated with whatever we end up using for #16379.

Hope this helps.

This is a huge help. Thank you!

I'll try and address items 4, 6 & 7 this weekend, if no one beats me to them.

[lessbloat]

Sorry don't know how the .2 got in there at the end... :-)

In 21283.12.2.diff​ I:

• re-added the box-shadow and border for .wp-full-overlay-header.
• removed focus event from .dropdown (focus was the wrong event to use here)
• added keydown event to .dropdown ('enter' key only)
• Added keydown event for "remove image" link ('enter' key only)
• Added keydown event for "collapse" link ('enter' key only)

[lessbloat]

Remaining tasks (that I know of), that I'd love help with:

1) "Select a file" keydown event. I spent about an hour trying to fix this over the weekend with no success. Using the enter key to trigger the browser file upload dialog is usually baked in (including in other areas of the admin where we use plupload). But for whatever reason, in this implementation it doesn't work.

2) grahamarmfield suggested putting the focus of the cursor back on the link that was clicked to enter the customizer. I'm honestly not quite sure where to implement this, and it becomes slightly complex because the customizer can be triggered from additional places (i.e. the welcome screen), so we cannot hard code a focus on the "customize" link on the themes page on close.

3) I have zero experience working with Dragon Naturally Speaking. Anyone have suggestions for ways to resolve comment:58?

[lessbloat]

21283.14.diff​ is a cleaned up patch for comment:62.

[nacin]

In 22731:

Customizer: Let return/enter fire click events for dropdowns and links. Remove errant focus event. Re-add box shadow and border for the overlay header. props lessbloat. see #21283.

[koopersmith]

1) A keydown event on "Select a File" will be hard, as plupload dynamically positions a transparent layer over the actual button if the browser does not support HTML5. We might be able to wire into the plupload internals to make it work.

2) We could track the link that was used to open the customizer in customize-loader and restore focus on close.

3) This was the biggest thing during the accessibility testing nacin and I saw — Dragon picks up everything on the page, and inserts its labels *below* the customizer on the page. Honestly, the best solution is probably to bump to customize.php if they're using dragon. That said, I have no idea how to detect Dragon.

---

At the end of the day, I think fixing the second point (link tracking) the best we're going to do for 3.5. The other two aren't really feasible at this point.

[grahamarmfield]

Replying to koopersmith:

2) We could track the link that was used to open the customizer in customize-loader and restore focus on close.

That would be good.

3) This was the biggest thing during the accessibility testing nacin and I saw — Dragon picks up everything on the page, and inserts its labels *below* the customizer on the page. Honestly, the best solution is probably to bump to customize.php if they're using dragon. That said, I have no idea how to detect Dragon.

I'd doubt that it's possible on the browser to detect that Dragon is running, and I also doubt that there's anything in the HTML headers. I could be wrong though so it'd be worth having a look. Many people have asked the same question about screen readers such as NVDA and JAWS but no-one has come up with a robust solution.

---

At the end of the day, I think fixing the second point (link tracking) the best we're going to do for 3.5. The other two aren't really feasible at this point.

I acknowledge that the cut-off for 3.5 must be very close. I'm a pragmatist, and believe that retrofitting accessibility to something complex like the WP admin screens is always going to be done by a series of steps in the right direction - rather than all at once.

That said, the scope of the a11y changes in 3.5 is impressive and I hope the pace can continue in 3.6.

If there's going to be a 'ground-up' rebuild of WP UI (for WP4 maybe) then there is a golden opportunity to bake all the accessibility in from the start.

[nacin]

Okay, so, remaining task that is a possible 3.5 candidate:

• We could track the link that was used to open the customizer in customize-loader and restore focus on close.

[lessbloat]

Replying to nacin:

Okay, so, remaining task that is a possible 3.5 candidate:

• We could track the link that was used to open the customizer in customize-loader and restore focus on close.

Done in 21283.15.diff​.

[koopersmith]

In 22756:

Customizer: Track the link that was used to open the customizer and restore focus on close. props lessbloat. fixes #21283.

[grahamarmfield]

Replying to koopersmith:
Not purely accessibility related, but there are some strange things happening in Theme Customizer in Google Chrome 23 on Windows 7.

How to recreate:

1. Navigate to Appearance -> Themes page.
2. Using keyboard, tab to Customize link and action. Panel opens as expected.
3. Tab down to Header Image and change. Then interact with background image.
4. Tab down to Navigation and press Enter - half of all the Customizer sections disappear!

[grahamarmfield]

Works fine in FF17 and IE9.

[SergeyBiryukov]

"Select a file" link in Background Image section doesn't work when trying to open it from keyboard (pressing Enter does nothing). Tested in Firefox 17 and Chrome 23.

[lessbloat]

Replying to grahamarmfield:

Not purely accessibility related, but there are some strange things happening in Theme Customizer in Google Chrome 23 on Windows 7.

How to recreate:

1. Navigate to Appearance -> Themes page.
2. Using keyboard, tab to Customize link and action. Panel opens as expected.
3. Tab down to Header Image and change. Then interact with background image.
4. Tab down to Navigation and press Enter - half of all the Customizer sections disappear!

Hey grahamarmfield, can we open a new ticket for this one (since it's not related)?

[lessbloat]

Replying to SergeyBiryukov:

"Select a file" link in Background Image section doesn't work when trying to open it from keyboard (pressing Enter does nothing). Tested in Firefox 17 and Chrome 23.

An attempt to tie these threads together... Koopersmith addressed this in comment:67. "We might be able to wire into the plupload internals to make it work".

[helenyhou]

Let's open new tickets for specifics, please.

[grahamarmfield]

Replying to helenyhou:

Let's open new tickets for specifics, please.

OK, will do.

[SergeyBiryukov]

Follow-ups: #22591, #22606