Make WordPress Core

Opened 14 years ago

Closed 11 years ago

Last modified 8 years ago

#14045 closed enhancement (fixed)

Give the menus page an accessibility mode option, like the widgets screen.

Reported by: quanin's profile quanin Owned by: markjaquith's profile markjaquith
Milestone: 3.6 Priority: normal
Severity: normal Version: 3.0
Component: Accessibility Keywords: 3.6-menus has-patch commit
Focuses: Cc:

Description

At present, the screen to create new nav menus lacks an ability to turn off drag/drop functionality. That poses an accessibility problem when trying to order menu items. The widgets page solves that problem by giving you the option to enable an accessibility mode, disabling drag/drop and giving you an easier option to position widgets according to your preference. I'd like to see the functionality introduced there incorporated in the creation/modification of nav menus if at all possible. Otherwise, accessibility-wise that feature is only partially useable.

Attachments (8)

14045.diff (6.1 KB) - added by lessbloat 11 years ago.
14045.1.diff (13.1 KB) - added by lessbloat 11 years ago.
14045.2.diff (13.7 KB) - added by lessbloat 11 years ago.
14045.3.diff (19.0 KB) - added by lessbloat 11 years ago.
14045.4.diff (5.0 KB) - added by SergeyBiryukov 11 years ago.
14045.5.diff (5.3 KB) - added by SergeyBiryukov 11 years ago.
14045.oneThemeLocationNoMenus.diff (1.9 KB) - added by SergeyBiryukov 11 years ago.
14045.6.diff (6.3 KB) - added by SergeyBiryukov 11 years ago.

Download all attachments as: .zip

Change History (72)

#1 @filosofo
14 years ago

Currently the up/down arrows are there, just hidden when JavaScript is enabled. Perhaps there could be a better way to expose them.

Or perhaps we could make it possible to move menu items that have focus, using the arrow keys.

#2 @nacin
13 years ago

  • Milestone changed from Awaiting Review to Future Release

#3 @quanin
13 years ago

  • Cc james@… added
  • Version changed from 3.0 to 3.1

I'd like to see something similar to what wp-admin/widgets.php does. Under screen options, you have the ability to enable accessibility mode. Then, it's a matter of editing the particular menu item and choosing where to stick it according to one or more combo boxes and/or radio buttons. That's far more accessible than randomly hitting the arrow keys and hoping the thing's moving to where you want it to exist.

#4 follow-up: @filosofo
13 years ago

If the response to arrow-clicking is random, then that's a bug that should be fixed.

The problems with having an entirely separate system of menu-editing include the fact that it will be unknown to most users and more likely to break (because it's getting less attention).

#5 in reply to: ↑ 4 @quanin
13 years ago

Replying to filosofo:

If the response to arrow-clicking is random, then that's a bug that should be fixed.

No. The problem is there's not a screenreader currently in existence with the ability to track and appropriately announce the new position of menu items when you've used the arrow keys to move them. If you want menu item 8 to be between items 1 and 2, you're escentially guessing. You hit the arrow key in question, stop, make sure the item in question actually moved in the direction you want it to, make sure the screenreader hasn't accidentally ended up on the menu item now below it as a result, and repeat. You can check visually to make sure the menu item(s) you're moving actually go where they're supposed to. We can't.

The problems with having an entirely separate system of menu-editing include the fact that it will be unknown to most users and more likely to break (because it's getting less attention).

Assuming the menu editing system isn't drasticly changed between versions, that should be a non-issue. If it's too major a concern, then don't make a separate menu editing system. Just make this one more useable with adaptive technology.

#6 @grahamarmfield
12 years ago

  • Version changed from 3.1 to 3.4.1

This is linked with another new ticket: #21289

#7 @grahamarmfield
11 years ago

Hopefully to get some attention in 3.6.

#8 @DrewAPicture
11 years ago

  • Cc xoodrew@… added
  • Type changed from defect (bug) to enhancement
  • Version changed from 3.4.1 to 3.0

Let's stick with the version the enhancement was first suggested.

I also think it would be nice to look at this in 3.6.

#9 @SergeyBiryukov
11 years ago

#21289 was marked as a duplicate.

#10 @SergeyBiryukov
11 years ago

  • Keywords needs-patch 3.6-early added

#11 @SergeyBiryukov
11 years ago

#22485 was marked as a duplicate.

#12 @adamsilverstein
11 years ago

  • Cc ADAMSILVERSTEIN@… added

#13 @helen
11 years ago

  • Milestone changed from Future Release to 3.6

Seems like patches on #23119 incorporate this, but it would be good to see the accessibility piece discussed separately here, as #23119 is a bit of a marathon ticket.

#14 @DrewAPicture
11 years ago

  • Keywords 3.6-menus added

#15 @sharonaustin
11 years ago

  • Cc sharonaustin added

To make more usable with adaptive technology, what's the possibility of adding a priority box, similar to the Order feature in Page Attributes, to the menu items?

Alternatively, perhaps having a visible link for alternative accessibility mode, similar to the one in place for widgets? This would address the problem mentioned above concerning the separate system of menu-editing being missed because it is unknown to users (See comment 5).

#16 @ceo
11 years ago

  • Cc ceo@… added

#17 @jkudish
11 years ago

  • Cc jkudish added

#18 follow-up: @grahamarmfield
11 years ago

  • Cc graham.armfield@… added

I think the two key bits of information about hierarchy for each item in the menu list that will need to be externalised in an accessibility option are:

  • The parent of the item - could be none of course
  • The menu order

The parent could be presented as a dropdown of all items in the currently selected menu apart from the current item. Maybe the hierarchy could be included here - eg About Us (Top level) but I'm not sure it's necessary.

The menu order could be a text box with the current order shown. I'm not sure if the menu order value is the absolute value within the menu or is relative to siblings. Also, I'm not sure how menu functionality would work if multiple items have the same menu order value. Perhaps someone could comment here.

Obviously all the other items - class, menu text, etc would need to be available too.

Not sure if all the data for a menu item needs to be visible all the time - that could mean a LOT of input fields visible all at once on complex menus. Maybe each item could be given a link that would open the options panel for that item - Show options (for About Us). A non-js fallback would have to be having them all visible I guess.

Doing it that way could allow the menu items to be presented in nested lists which of course could help with the understanding of current hierarchy - a bit like how the menus would be likely presented on the front end.

Bit short of time at present but may try and mock up some screenshots for comments.

#19 @quanin
11 years ago

What if menu items *couldn't* have the same order value? Again I refer you to how it's handled by widgets presently. The possible order values range from 1 to n+1, where n is the last item in the list. The only difference is I don't *think* you'll need the radio buttons on the menu screen to select where to drop that menu--considering, if I'm seeing things right as of 3.5.1, there's a custom menu widget that serves that purpose. Someone can feel free to correct me if I'm off base.

#20 in reply to: ↑ 18 @ceo
11 years ago

Replying to grahamarmfield:

Also, I'm not sure how menu functionality would work if multiple items have the same menu order value. Perhaps someone could comment here.

I believe in terms of page hierarchy it is/was then based on the ID; this could also work for menu items since they have an ID as well. (Technically, that is what happens anyway, if you don't move anything within the menu screen.)

@lessbloat
11 years ago

#21 follow-up: @lessbloat
11 years ago

14045.diff​ attempts to add accessibility without the need for a separate screen.

How does it work?

When you focus on a primary menu item using a screen reader you'll hear something like: "About. 2nd of 4 primary menu items. Move this item up, down, or right." Where "About" is the name of the menu item.

When you're on a sub menu item, you'll hear: "Jobs. 1st of 3 sub menu item under About. Move this item up, down, or left."

#22 @DrewAPicture
11 years ago

  • Keywords has-patch added; needs-patch removed

#23 in reply to: ↑ 21 ; follow-up: @quanin
11 years ago

Replying to lessbloat:

14045.diff​ attempts to add accessibility without the need for a separate screen.

How does it work?

When you focus on a primary menu item using a screen reader you'll hear something like: "About. 2nd of 4 primary menu items. Move this item up, down, or right." Where "About" is the name of the menu item.

When you're on a sub menu item, you'll hear: "Jobs. 1st of 3 sub menu item under About. Move this item up, down, or left."

That's way too much info for a screenreader, in my honest opinion. When I'm doing what I do, I need to be able to do it quickly. If I'm having to wait for the screenreader to finish with reading me the menu name, it's location, and what I can do with it, that'll take too long.

Additionally, drag/drop doesn't really work from a screenreader angle. Noteably because not all screenreaders support it, nor do the ones that do support it the same way.

Note: You may not have been thinking drag/drop. But since you didn't clarify exactly how things would be rearanged, I'm assuming that's what you're going for.

#24 in reply to: ↑ 23 ; follow-up: @lessbloat
11 years ago

Replying to quanin:

Replying to lessbloat:

14045.diff​ attempts to add accessibility without the need for a separate screen.

How does it work?

When you focus on a primary menu item using a screen reader you'll hear something like: "About. 2nd of 4 primary menu items. Move this item up, down, or right." Where "About" is the name of the menu item.

When you're on a sub menu item, you'll hear: "Jobs. 1st of 3 sub menu item under About. Move this item up, down, or left."

That's way too much info for a screenreader

So, that was my worry. Is there any way we could pare it down to something that is manageable?

Note: You may not have been thinking drag/drop. But since you didn't clarify exactly how things would be rearanged, I'm assuming that's what you're going for.

Sorry, to clarify: you can now re-arrange menu items both via drag/drop and also via your keyboard arrows.

#25 in reply to: ↑ 24 ; follow-up: @quanin
11 years ago

Replying to lessbloat:

So, that was my worry. Is there any way we could pare it down to something that is manageable?

This is why I suggested an accessibility mode screen option, similar to the widget page presently. If enabling that mode will make those modifications, it can be documented on the screen that gives you the option of enabling that mode. That way, if you don't need to see/hear it, you won't see/hear it.

Note: You may not have been thinking drag/drop. But since you didn't clarify exactly how things would be rearanged, I'm assuming that's what you're going for.

Sorry, to clarify: you can now re-arrange menu items both via drag/drop and also via your keyboard arrows.

Navigating via keyboard arrows isn't all that intuitive. Screenreaders tend to use the keyboard arrows primarily for their own purposes, IE: to actually read a webpage. While someone like you or I might know we'll need to bypass that every time we want to shift a menu item a step to the left or right, that can't be said for every user out there. Plus, again, whether or not you'll have to, and how you'd go about doing that--assuming it's doable in the first place, is entirely screenreader dependent. I'd ideally like to see something a little bit more universal. It's why when the ticket was created I used the widget page as an example/guideline.

As a point of reference: the screenreader I use, JAWS for Windows, gives you an option to bypass its standard uses of the arrow keys. However, you'll need to issue its bypass command every time you wanted to shift a menu item up, down, left, right etc. If you're dealing with a lot of menus/submenus, that can actually subtract from useability--something accessibility should, ideally, never do.

#26 in reply to: ↑ 25 @ceo
11 years ago

Replying to quanin:

It's why when the ticket was created I used the widget page as an example/guideline.

14045.diff is just a potential solution and one that was proposed to test specifically to see if the functionality could work. No one is entirely ruling out the widget screen accessibility mode as a means of accomplishing this, but even that has functionality as yet to be determined. (In fact, a mockup is being worked on as was discussed in the accessibility group's IRC meeting yesterday.)

FWIW, I just tested 14045.diff and basically confirmed your above suspicions as a JAWS user myself.

#27 follow-ups: @lessbloat
11 years ago

Replying to quanin:

I really appreciate your feedback, and your patience (I'm fairly new to designing for accessibility, I'm still figuring this all out).

Consider this a first attempt at finding a solution. A failed first attempt. ;-)

I'll take another stab at it, and report back.

#28 @lessbloat
11 years ago

  • Keywords has-patch removed

#29 in reply to: ↑ 27 @quanin
11 years ago

Replying to lessbloat:

Replying to quanin:

I really appreciate your feedback, and your patience (I'm fairly new to designing for accessibility, I'm still figuring this all out).

Consider this a first attempt at finding a solution. A failed first attempt. ;-)

I'll take another stab at it, and report back.

It's hardly a failed attempt. In theory, you're right. I actually wish it was as easy as that. But, blame adaptive tech folks. I do it daily.

#30 in reply to: ↑ 27 @esmi
11 years ago

Replying to lessbloat:

I'll take another stab at it, and report back.

Whilst you're in there, is there any chance of some focus highlighting for the sighted keyboard navigators? Once I'm within the menu itself trying to re-order it, it's really difficult to see where the current focus is. A color change or an underline would go a long way towards easing this.

With regard to the verbiage (and bearing in mind that I am NOT a qualified SR reader by any stretch of the imagination), I think you're on the right track by putting the unique info first. What if "Jobs. 1st of 3 sub menu item under About" was changed to "Jobs. 1 of 3 in About"? Could we drop "Move this item up, down, or left" on each item in favor of putting a generalised instruction line in clear text at the top? Something along the lines of "If you're navigating by keyboard, use the arrow keys to re-order items"?

Just a thought...

#31 @grahamarmfield
11 years ago

Echoing what quanin said - this is not a failed attempt. It's an interesting concept and could potentially be the basis for a workable solution. So thanks for havng a go.

I am nervous about the verbosity but esmi's concise solution could help there.

I'm also unsure about the issue of using the arrow keys to influence 'movement' of an item. When using screen readers the arrow keys are normally associated with moving around within the page. I've just tested this functionality on NVDA on Firefox and I can't get the arrows to work without the override keystroke command. It would be a real pain for people to have to do that override every time they want to move an item - even though they probably won't be changing their menus every day.

Could the necessary 'move' commands be included as text within the dropdown panel? That way, screen reader users could open the panel to access the options (which they might want to do anyway) and they would find the text links to influence the position. The challenge would be to find the right language to convey what we're trying to achieve here. Left and right aren't right here I feel. Knowing which way to move the item presupposes you have the 'sighted' model in your head.

But since we have more space here could the links not be 'Move item before About Us', 'Make this item a sub-page of About Us', etc. These links describe more clearly what the action would be.

The benefit of doing it that way would be that speech recognition users would also have some nice clear text links to use - it had been troubling me how VR users would a) discover what they need to do and b) influence items using voice commands only. Drag and drop is of course possible in software like Dragon Naturally Speaking, but it's laborious to get it right when compared to just saying "Click this".

For VR users I'd want to see a text link on each 'at rest' menu item. The down arrow has no obvious text equivalent for VR users, and it would be poor for us to force mouse moving or mouse grid just to avoid an Options link.

Also to echo esmi's comment - focus highlighting is always important.

Last edited 11 years ago by grahamarmfield (previous) (diff)

#32 @sscovil
11 years ago

  • Cc sscovil@… added

@lessbloat
11 years ago

#33 follow-up: @lessbloat
11 years ago

For 14045.1.diff​:

I took @esmi's advice and shortened the amount of info you hear when you focus on a menu item.

For primary items, you'll hear something like: "Home. 1st of 5 primary items."

For sub items, you'll hear something like: "Contact us. 1st sub item under About."

Then, once you click into a menu item (by pressing enter on focus), based on @grahamarmfield's advice, you'll see new "reorganize" links just above the existing remove and cancel links. I've named them "Move up", "Move down", "Move left", and "Move right" for now, but we can add more context there if this solution appears to be heading in the right direction.

p.s. I'll have a play with focus highlighting too, just want to try and nail down this bigger stuff first.

Let me know what you think.

#34 @ceo
11 years ago

Overall I think 14045.1.diff​ works pretty well for use with a screen reader. I really like that when the item moves, it announces the new location. The shortened verbage for each menu item when navigating is also a big plus.

I think the reorganization links might benefit from being worded in a more descriptive way. Especially in terms of "nesting" menu items. I'm not sure of a good phrase to use, but I think it would be wonderful if it's possible for the link to pull from the actual menu information, i.e., state that the item could be nested under "Jobs" for instance.

#35 follow-ups: @quanin
11 years ago

Ideally I was hoping to maybe get away from links where possible, but it's a decent enough start. The reason being I don't know that we want them messing with the tab order for everything else--for those folks who rely on that method. I was thinking we could add something to the "edit menu" and "edit menu item" screens such that you have a list of menus and appropriate menu items to deal with. And, for submenus, perhaps a "parent of"field--similar to child pages or subcategories.

I was thinking a dropdown list for menus, indicating a list of the current menus available and aranging it so the new or edited menu is placed after whichever item is selected. Naturally, this would come with obvious markers for start and end of list, in the event someone wants to put a menu explicitly there. With menu items, radio buttons representing the current menus available and a dropdown indicating placement in the selected menu might be something to consider. In the alternative, I'd be onboard with giving both menus and menu items a priority field a la comment 15.

#36 in reply to: ↑ 35 @lessbloat
11 years ago

Replying to quanin:

Ideally I was hoping to maybe get away from links where possible, but it's a decent enough start. The reason being I don't know that we want them messing with the tab order for everything else--for those folks who rely on that method.

Sorry, I'm not sure I follow. Can you please explain what you mean by "messing with the tab order"?

#37 in reply to: ↑ 33 ; follow-up: @_Redd
11 years ago

lessbloat, there's overwhelming appreciation for this; we really can't thank you enough. It's amazing, just amazing, the work that went into this.

Do I understand it correctly that the adjustments to the nav menu affect the nav bar on top, but not the side menus? If you take a look at this test page, you can see that my top nav order has been affected, but the menu order in the sidebar, and on the menus page, has not.
(I tried to re-order page two of menu item two, by selecting "move up" and then selecting "save menu". I am a fully sighted user)

http://red-hound.com/test/page-one

What mistakes could I have made in setting this up?

And thank you, yet again!

#38 in reply to: ↑ 37 ; follow-up: @lessbloat
11 years ago

Replying to _Redd:

lessbloat, there's overwhelming appreciation for this; we really can't thank you enough. It's amazing, just amazing, the work that went into this.

No problem. I enjoy all of this. :-)

Do I understand it correctly that the adjustments to the nav menu affect the nav bar on top, but not the side menus?

To clarify, it looks like you have two menus (I'm guessing Menu 1, and Menu 2 based on your screenshot). In order to add one of these menus to your website, you'll want to select the "Navigation Menu" checkbox under theme locations and save the menu.

Menus by themselves don't show up anywhere unless you first assign them to a theme location, or manually add them to a custom menu widget.

Does that make sense?

#39 in reply to: ↑ 35 ; follow-up: @grahamarmfield
11 years ago

Replying to quanin:

I was thinking a dropdown list for menus, indicating a list of the current menus available and aranging it so the new or edited menu is placed after whichever item is selected. Naturally, this would come with obvious markers for start and end of list, in the event someone wants to put a menu explicitly there. With menu items, radio buttons representing the current menus available and a dropdown indicating placement in the selected menu might be something to consider. In the alternative, I'd be onboard with giving both menus and menu items a priority field a la comment 15.

I'm not quite sure if I've fully understood your proposal here. Within the individual menu items a dropdown to set the item's parent could be a good idea. The links to move items around can I believe only allow movement one slot at a time. Whereas a dropdown box could allow more radical moves in one go.

Consider an example from the future - supposing I have a menu structure:

  • Home
  • About Us
  • - Team Members
  • - Sponsors
  • Services
  • - Accessibility
  • - Coding
  • - Testing
  • Find Us
  • Contact
  • Blog

I create a new page 'Partners' that I want to place within the About Us section. When I add the page to the menu it will appear at the bottom of the list and using the up down commands only it would take about 8 steps to get the page into the right spot.

However, using a dropdown to set parent I could potentially achieve the same with just one step.

Tweaking the position within a given parent could be a link still or maybe a dropdown too (bit like accessible widgets).

#40 in reply to: ↑ 39 ; follow-up: @quanin
11 years ago

Replying to grahamarmfield:

I'm not quite sure if I've fully understood your proposal here. Within the individual menu items a dropdown to set the item's parent could be a good idea. The links to move items around can I believe only allow movement one slot at a time. Whereas a dropdown box could allow more radical moves in one go.

Consider an example from the future - supposing I have a menu structure:

  • Home
  • About Us
  • - Team Members
  • - Sponsors
  • Services
  • - Accessibility
  • - Coding
  • - Testing
  • Find Us
  • Contact
  • Blog

I create a new page 'Partners' that I want to place within the About Us section. When I add the page to the menu it will appear at the bottom of the list and using the up down commands only it would take about 8 steps to get the page into the right spot.

However, using a dropdown to set parent I could potentially achieve the same with just one step.

Tweaking the position within a given parent could be a link still or maybe a dropdown too (bit like accessible widgets).

You understand my proposal perfectly, good sir, and this example is exactly the one I was thinking of. I suggested radio buttons for the menus you could select from, similar to the radio buttons re: theme location placement for widgets (left sidebar, etc), but a dropdown list for menus could work exactly the same way.

The reason I suggested a "Parent of" field, though, was for--and admitedly I'm not sure if WordPress supports this--submenu creation. So you'd have, from your example above:

  • Home
  • About Us
  • - Team Members
  • - Sponsors
  • Services
  • - Accessibility
  • - Coding
  • - Testing
  • Find Us
  • Contact
  • Blog

Let's say you made the "Team Members" page a menu on its own, but within the "about" menu--so, for instance, your team can handle their own biographical info etc and emphasise whichever projects they're working on, etc.

  • Home
  • About Us
  • - Team Members
  • - - Jason
  • - - James
  • - - Graham
  • - Sponsors
  • Services
  • - Accessibility
  • - Coding
  • - Testing
  • Find Us
  • Contact
  • Blog

That submenu would be a child menu of the "about us" menu, so you should--ideally--be limited to selecting valid locations within that menu to asign the child. Hence, "parent of". Pages could still use either the radio button option or, like in your proposal, the two dropdown lists to choose menu location and position. Hopefully I didn't just muddle your nearly perfect understanding of my idea.

#41 in reply to: ↑ 40 ; follow-up: @ceo
11 years ago

Replying to quanin:

Let's say you made the "Team Members" page a menu on its own, but within the "about" menu--so, for instance, your team can handle their own biographical info etc and emphasise whichever projects they're working on, etc.

To me, this is already covered under what Graham has above. Any menu item can be a "parent" and have menu items nested under it.

If you want a separate menu, then that would literally be a separate menu; not a nested menu item. Combining those two types of functionality with menu creation - to me - seems like it's making the whole thing more complex and not less.

Granted this is only theoretical and my thoughts might change in practice, but personally, I'd like to refrain from making the accessibility options require too many extra settings because of just this. If the typical user is able to rearrange things with simple mouse drags, it seems to me that having more than three settings to choose from to accomplish the same thing is pushing it.

#42 in reply to: ↑ 41 ; follow-up: @quanin
11 years ago

Replying to ceo:

Replying to quanin:

Let's say you made the "Team Members" page a menu on its own, but within the "about" menu--so, for instance, your team can handle their own biographical info etc and emphasise whichever projects they're working on, etc.

To me, this is already covered under what Graham has above. Any menu item can be a "parent" and have menu items nested under it.

If you want a separate menu, then that would literally be a separate menu; not a nested menu item. Combining those two types of functionality with menu creation - to me - seems like it's making the whole thing more complex and not less.

Granted this is only theoretical and my thoughts might change in practice, but personally, I'd like to refrain from making the accessibility options require too many extra settings because of just this. If the typical user is able to rearrange things with simple mouse drags, it seems to me that having more than three settings to choose from to accomplish the same thing is pushing it.

That was the one area I wasn't entirely clear on. What with it not being useable to the visually impaired in its current form I haven't exactly had much of a chance to test it in-depth. But, if any menu item can escentially become the start of a new menu, then yes--that pretty much covers what I was thinking in the first place.

#43 in reply to: ↑ 42 @lessbloat
11 years ago

Replying to quanin:

Just wanted to clarify that each menu can be multiple levels deep (I think the max you can have is like 12 levels deep - imagine navigating that menu! ;-)). Quanin, your example of having "Jason" be a sub menu item of "Team Members" is perfectly legitimate, and possible (in the current version of WordPress, but only through drag and drop).

#44 in reply to: ↑ 38 @_Redd
11 years ago

Menus by themselves don't show up anywhere unless you first assign them to a theme location, or manually add them to a custom menu widget.

Does that make sense?

It does now....I had been looking for the old, "Make this your home menu" bar on the left, so your explanation clarified things for me. And, I like the feedback that came with it! There was no confusion as to which was the "navbar" menu when the box was checked! Thank you!

And you were right about having two menus...I put the second one up for display on the sidebar also, so I can keep track!

That said, I'm not able to re-order pages within the menu.

Or, at least, as a fully sighted user, I am not seeing the results.

For example, in Menu 2 I have five pages.

I was trying to re-order the pages (using page five as an example) by expanding the input screen for the attributes for Page Five, then selecting, "Move Up" with my mouse. The link changes color from blue to red, which is good, and when I click on it, and then "save menu" the page tries to refresh, but I am not seeing any results.

Sir, would you have any other recommendations?

FYI, this is a multisite setup. Could I have done something wrong with multisite to affect this?

And again, thanks SO much for everything!

@lessbloat
11 years ago

#45 @lessbloat
11 years ago

Had to tweak the voice over text to accommodate for localization in 14045.2.diff​.

It now reads:

  • "Home. Menu item 1 of 5" when you focus on a primary menu item, and
  • "Contact us. Sub item number 2 under About" when you focus on a sub menu item

Let me know if you see any issues with this.

#46 follow-up: @_Redd
11 years ago

Hi lessbloat, may I ask, what version of 3.6-alpha are you using for these diffs?

(My most recent update was to 3.6-alpha-23662 via the plugin)

And again, thankyou for everything!

#47 in reply to: ↑ 46 ; follow-up: @lessbloat
11 years ago

Replying to _Redd:

Hi lessbloat, may I ask, what version of 3.6-alpha are you using for these diffs?

(My most recent update was to 3.6-alpha-23662 via the plugin)

And again, thankyou for everything!

Hey _Redd,

All development happens in trunk. The changes I have uploaded here are only accessible via the patch attached to this ticket, which then must be applied to an instance of trunk (either running locally, or on a development server).

Nothing has been committed yet for this ticket. Once these changes have been committed by one of the devs (I don't have commit access), it will be available in the nightly builds for anyone to grab via a wp-admin update.

#48 @grahamarmfield
11 years ago

Hi @lessbloat, have had a proper chance to test all this now with screen reader and I have to say that the functionality works nicely - well done mate.

Also, with Dragon (in IE) it is possible to achieve most things without resorting to mouse commands or emulating tabbing - which is good. There are problems selecting any item in the menu that happens to be called Home directly as when you say "Click Home" it is misinterpreted - but this is not unusual for Dragon. There is a problem directly selecting anything other than the first Add Menu button on the page - I'm not quite sure why that is. That's one of the places where you have to resort to tabbing.

My two suggestions for improving the new menu screens are:

  • Change the manipulation links away from Move right, Move down to less visually-centric commands.
  • Add a heading to the top of the main panel where menu items can be manipulated - suggest "Current Menu" or similar. This will allow screen reader users to navigate straight to the section once they have added all the items they want to. Obviously that doesn't help sighted tabbing users though.

The potential issue I identified earlier about adding new items or moving items around an existing menu with many items still troubles me slightly, but I guess it's possible to outdent items to move them quicker. Perhaps we'll need to craft some help for screen reader users here.

#49 @grahamarmfield
11 years ago

@lessbloat I know this is purely prototype at the moment but just to point out, the orientation links don't update if an item's fields are visible and you then move it with a mouse (drag drop).

#50 in reply to: ↑ 47 @_Redd
11 years ago

Replying to lessbloat:
Awesome, thank you, lessbloat!

@lessbloat
11 years ago

#51 @lessbloat
11 years ago

14045.3.diff​ addresses a couple of things:

  • Fixes update bug mentioned in comment 49
  • Adds h3 headers for both the "Menu Structure" section, and the "Menu Settings" section
  • Changes the Rearrange links to be Move: "Up one", "Down one", "Under Home" (where home is the nearest parent item), and "Out from under Home" (when an item is a sub item of home).
  • Added a bonus "To top" rearrangement link (helpful when a menu item is added to the bottom of a long list of menu items)
  • Moved JS vars to be included via wp_localize_script

#52 @markjaquith
11 years ago

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

In 23727:

Accessibility revamp for nav menus.

props lessbloat. fixes #14045

#53 follow-up: @SergeyBiryukov
11 years ago

  • Keywords has-patch commit added; 3.6-early removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

For proper i18n, we should always use placeholders in strings where possible instead of manual concatenation.

Also, concatenating 'Move' with other strings starting with a capital letter doesn't look good in languages where a capital letter is typically only used at the beginning of the sentence (e.g. Russian).

14045.4.diff fixes that.

#54 in reply to: ↑ 53 ; follow-up: @adamsilverstein
11 years ago

Replying to SergeyBiryukov:

For proper i18n, we should always use placeholders in strings where possible instead of manual concatenation.

Also, concatenating 'Move' with other strings starting with a capital letter doesn't look good in languages where a capital letter is typically only used at the beginning of the sentence (e.g. Russian).

14045.4.diff fixes that.

thanks for adding that, i was wondering about the best method for including translated strings when working on the revisions backbone code, this is a much cleaner approach than what i thought of!

quick question: how would you deal with strings where plural word is different, where you would usually use _n()?

#55 in reply to: ↑ 54 @SergeyBiryukov
11 years ago

Replying to adamsilverstein:

quick question: how would you deal with strings where plural word is different, where you would usually use _n()?

#22229 would be a long-term solution for plurals in JS.

In the meantime, we might be able to get away with a workaround similar to the one in #22749.

#56 @SergeyBiryukov
11 years ago

14045.5.diff makes placeholders numbered where appropriate (just in case) and adds translator comments.

#57 follow-up: @GaryJ
11 years ago

In [23727], the variable in nav-menu.js is menu.oneThemeLocationNoMenus, yet the localized object is menus, making the property menus.oneThemeLocationNoMenus.

#58 in reply to: ↑ 57 ; follow-up: @SergeyBiryukov
11 years ago

Replying to GaryJ:

In [23727], the variable in nav-menu.js is menu.oneThemeLocationNoMenus, yet the localized object is menus, making the property menus.oneThemeLocationNoMenus.

Fixed the object name, but then got strange results: all the items from Pages meta box were copied to the menu without my intention. I already had two menus, so oneThemeLocationNoMenus should have been false.

It occured to me that 'false' as a string (in wp-admin/nav-menus.php, line 358) still evaluates to true, which I guess caused this.

lessbloat, could you confirm that 14045.oneThemeLocationNoMenus.diff works as intended?

14045.6.diff is the combined patch.

Last edited 11 years ago by SergeyBiryukov (previous) (diff)

#59 @GaryJ
11 years ago

I can confirm the duplicate addition of menu items. The page loads fine, then JS kicks in, and each of the Pages gets added as a new menu item, in the same order as the View All tab, above the existing menu items.

14045.oneThemeLocationNoMenus.diff fixes the duplication for me (I have more than one theme location and several menus, so the original purpose of this conditional isn't applicable to my setup.)

#60 in reply to: ↑ 58 @lessbloat
11 years ago

Replying to SergeyBiryukov:

lessbloat, could you confirm that 14045.oneThemeLocationNoMenus.diff works as intended?

14045.6.diff is the combined patch.

I tested 14045.6.diff which looks good, and works as expected for me.

#61 @SergeyBiryukov
11 years ago

In 23760:

Fix object name. props GaryJ. see #14045.

#62 @SergeyBiryukov
11 years ago

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

In 23761:

Use placeholders in menu strings instead of manual concatenation. fixes #14045.

#63 @ocean90
11 years ago

In 24702:

Nav Menus: Hide the rearrange section in no-js. see #14045.

This ticket was mentioned in Slack in #accessibility by cheffheid. View the logs.


8 years ago

Note: See TracTickets for help on using tickets.