Media modal: add more headings to better identify the main sections and improve content navigation for assistive technology users

[afercia]

One of the historical issues within the media modal is that content navigation for keyboard and assistive technology users is challenging.

For example, when the media grid has many attachments, users are forced to navigate through all the attachments to get to the sidebar or to go back to the menu on the left. Dozens or hundreds of key presses are required, depending on the amount of attachments displayed.

With the introduction of the new Heading media view. and improving some of the existing media templates, it is now possible to easily add more headings in the media modal.

Users of assistive technologies use headings as the ​predominant mechanism for finding page information. Screen readers provide keyboard shortcuts and other tools to "jump" through headings, thus making content navigation way more efficient. Also, ​a correct headings hierarchy is extremely important to allow users to get a sense of how content is organized.

Currently, there are 4 headings in the media modal:

Note: this varies depending on the actual media "frame" being used.

In #47145, the proposed patch moves the main H1 heading before the menu so that it's the first thing within the modal content.

I'd like to propose to add a few more headings, at the very least:

• before the left menu
• before the selects to filter attachments and the search field
• before the "current selection" area in the bottom bar

Ideally, these headings should be visible because clearly identifying content sections helps all users. Worth noting headings don't necessarily need to be styled with a "big" font size. They just have to use the correct heading level and establish some typographic hierarchy.

Where there's not enough space, one option to evaluate could be hiding the headings visually using the CSS class screen-reader-text.

[afercia]

See some initial design feedback on this related ticket comment: https://core.trac.wordpress.org/ticket/47145#comment:9
/Cc @kjellr @melchoyce

[karmatosed]

@afercia with #47145 committed does that now need to come here and we remove the feedback keyword for design?

[afercia]

@karmatosed @kjellr the initial design proposal in https://core.trac.wordpress.org/ticket/47145#comment:9 is not implemented yet. We agreed to address design changes on this ticket, if need be.

I'd like to add a heading before the left menu. Preferably a visible heading. I guess this requires design feedback.

The problem I'd like to try to solve is that some sections of the media modal dialog are not identified by a heading. See attached screenshot below. For screen reader users, ​headings are still the predominant mechanism to find information.

Other places that would need a heading:

• before the selects to filter attachments and the search field
• before the "current selection" area in the bottom bar

[afercia]

Some sections of the media modal dialog are not identified by a heading

[kjellr]

Thanks, @afercia. Moving that mockup over here for easy reference:

Regarding those additional headings, I just want to work through the location and labels for each of the new ones. Does this sum it up?

1. Header above the left menu. Potential text: "Menu", "Media Menu"
2. Header next to dropdown + search field. Potential text: "Filter" "View:"
3. Header next to the currently selected area. Potential text: "Current Selection", "Currently Selected"

[afercia]

@kjellr yup, those three are the places that needs headings. Not sure about the text to use, but we can iterate :)

[afercia]

Discussed during today's accessibility bug-scrub. Agreed that visible headings would be preferable.

Re: potential text for the headings:

In the Posts list, WordPress uses some visually hidden headings, for example:

• Filter posts list
• Posts list

For the list of attachments, the media modal dialog already uses a visually hidden heading:

• Attachments list

Similarly for the related filters I'd suggest:

• Filter attachments list

Note related to copy: all the items in the left menu start with a verb except "Featured image", not sure why:

Add Media
Create Gallery
Create Audio Playlist
Create Video Playlist
Featured Image
Insert from URL

[kjellr]

@karmatosed has volunteered to make some new mockups with those headers, so I'm assigning to her for now. 🙌

[afercia]

Pending design feedback, 47610.diff​ is a first pass to add new headings. For now, they're visually hidden.

• Menu
• Filter attachments
• Available actions

I opted for "Available actions" because this heading needs to identify the bottom toolbar. Depending on the frame and flow, this toolbar can have the current selection state and the "insert/select" button (actually the button text varies and can be set via options). There's the need of a heading text that is generic enough and "Available actions" sounded decently meaningful to me.

I'd appreciate feedback from the media component maintainers and backbone experts to make sure these new headings are rendered on all the various frames.

Screenshot:

[afercia]

Additionally: the patch improves the %d selected text for the current selection by using wp.i18n._n. Kept the old PHP string for backwards compatibility with plugins that might be using it.

[karmatosed]

Noting I removed myself this needs feedback so sitting assigned doesn't make sense as to way we've worked in past. I am not saying feedback won't be given. As we have a first pass now it is important to focus on that.

[karmatosed]

Pending design feedback, 47610.diff​ is a first pass to add new headings. For now, they're visually hidden.

Let's get some clarity here though as I read this as 'no need for design'. @afercia are you suggesting you still need mocks?

[afercia]

@karmatosed as pointed out in a couple of the previous comments, the accessibility team recommends visible headings. In 47610.diff​ I made them visually hidden just because there's no design feedback yet. So yes, this ticket still needs design, please.

Of the 3 new headings, I'd be fine in keeping the "Available actions" one (the one for the bottom toolbar) visually hidden. The other two new ones: "Menu" and "FIlter attachments" would better serve users if they're visible.

[karmatosed]

Ah, thanks for the clarification, I will work on mocks for you tomorrow and change this to needs-design in that case as keyword.

[karmatosed]

I worked on a few iterations. I do, however, have some reservations over labelling all 3 places. My reluctance is we aren't doing elsewhere in the interface so it does both create a large amount of cognitive load and inconsistency. Similarly, because the only style to reuse is uppercase, that creates comprehension issues for those for example with dyslexia. However, here is an example of 'all' labels - from a design perspective I would advise against this all on version:

I have shortened to 'filter' as I am unsure this needs to explicitly say attachments due to location.

An iteration that balances cognitive load, comprehension and accessibility hopefully is:

[kjellr]

I think the labels in the first mockup seem like the clearest path forward, but I agree that we historically don't have visible labels in some of those areas. For instance, we don't currently include filter labels or "Currently x items selected" labels in other areas of WP-Admin:

Should those areas include visible labels too?

Regarding the "Menu" label at the left: I wonder if there's a more descriptive title there. "Menu" seems a little superfluous. Perhaps something like "Actions" or "Media Actions"?

[afercia]

Thanks both for your feedback.

I worked on a few iterations. I do, however, have some reservations over labelling all 3 places. My reluctance is we aren't doing elsewhere in the interface so it does both create a large amount of cognitive load and inconsistency.

It often happens to have different views from a design vs. an accessibility perspective. However, we should clarify some things.

Re: "reservations over labelling all 3 places": these are not "labels" nor just text. They're headings. Headings identify the main sections of a UI and give a HTML document its structure. In a project that aims to be as much accessible as possible, I'd like to see the design take information architecture and semantics into consideration since the beginning.

A good user interface should serve the same content to all users. Every time we visually hide something to make it available only to screen reader users, we're actually violating this principle. It's a historical compromise often used in WordPress but visible headings would benefit a lot of users, regardless of their ability level.

The fact "we aren't doing elsewhere in the interface" means to me that we should improve also other areas of the interface :)

it does both create a large amount of cognitive load

Please don't take me wrong but seems to me this is a very subjective opinion. Is there any user research or data to support that the addition of a few visible headings adds a tremendous cognitive load? Instead, I'd like to remind that accessibility principles come from years and years of user testing and research.

Aside: as said in a previous comment, from a visual perspective headings don't necessarily need to be "big" or bold.

Similarly, because the only style to reuse is uppercase, that creates comprehension issues for those for example with dyslexia.

I'd be in favor of making all the headings in the media modal use sentence case. All uppercase should generally be avoided and this is a good opportunity to change it.

I have shortened to 'filter' as I am unsure this needs to explicitly say attachments due to location

Shortening to "Filter" doesn't seem ideal to me. It doesn't tell me the "what". Let's imagine a blank canvas with a few sections. These sections have headings. One of them says "Filter": as a user, I wouldn't have a clue what this section is about.

Also, the placement on the left of the select doesn't seem ideal to me. This way, it looks like the select <label> element. Instead, it needs to identify the whole section including the search.

Should those areas include visible labels too?

@kjellr those other areas like the Posts screen do have headings, see for example the "Filter posts list" h2 :) They're visually hidden because there was no consensus to make them visible. I'd be happy to create new issues and propose to make them visible :)

Regarding the "Menu" label at the left: I wonder if there's a more descriptive title there.

Right. On #47149 it was proposed to use "media types" which sounds a bit better. However, all the menu items are verbs: Add, Create, Insert. They represent actions instead of media types. Except "Featured Image" which is inconsistent with all the other items.

[kjellr]

I'd like to see the design take information architecture and semantics into consideration since the beginning.

For sure! I think this is the crux of the problem here. Semantic headings for these areas clearly weren't baked in when the page was designed originally (sounds like many other screens have the same issue). It's much harder to get these headings integrated after the fact. I do hope with open dialogs like this, we're able to prevent these sorts of mistakes moving forward.

Regarding the task at hand, this particular layout is really packed as is — there are two sidebars, a top bar, a bottom bar, and a middle area. It's hard to put more of anything in at this point. That's also a big factor here. In any case, it sounds like something like this is more what we're looking for?

The placement and treatment of these labels seems pretty reasonable and organized. Let me know what you think.

I'd be in favor of making all the headings in the media modal use sentence case. All uppercase should generally be avoided and this is a good opportunity to change it.

I agree, but only if we can make that change globally for the Modal (and bump up the size from 12px to 13px. 🙂). If not, I'd prefer not to introduce another heading style. This may be more appropriate for a separate ticket.

Right. On #47149 it was proposed to use "media types" which sounds a bit better. However, all the menu items are verbs: Add, Create, Insert. They represent actions instead of media types. Except "Featured Image" which is inconsistent with all the other items.

Thanks — I do think "Media Types" is a better label. It would be great to change "Featured Image" to "Edit Featured Image" to make them all actions at some point.

[karmatosed]

I would second the iteration @kjellr has worked on here. I think for now adding a new header style is a lot but it absolutely is worth a ticket to consider later. Similarly, I agree we have reached the limit of this interface so appreciate what everyone is doing to work in confines.

[afercia]

@kjellr @karmatosed thanks! The mockup on comment 24 addressed the accessibility issue. A few things:

• "filter" still needs to explain the "what" so I'd like that heading to be "Filter attachments"
• "Current": I think this needs to identify both the selection area and the buttons area on the right. In the latest patch, the heading is "Available actions" for that reason. Actions being:
  • editi selection / clear selection
  • insert (this one changes text depending on the flow and can also be set by plugins)
  • I'd be fine to keep it visually hidden
• Shall I proceed with changing the headings to sentence case 13 pixels or not? :)

[karmatosed]

I will let @kjellr add thoughts but for me:

"filter" still needs to explain the "what" so I'd like that heading to be "Filter attachments"

I worry about translations here but not sure there is a midpoint, so in this case let's have that.

I am a little confused what you mean by current needing to be referring to both. Do you mean the phrase 'current' appearing twice? If you are ok leaving visually hidden for now, let's do that as we can always iterate in beta based on clarification.

Shall I proceed with changing the headings to sentence case 13 pixels or not? :)

I feel no, because we can use an existing style and explore beyond. I would love to have more than my opinion on this though.

[afercia]

47610.2.diff​ refreshes the patch and:

• adds 3 headings:
  • Media Types
  • Filter Media
  • Available actions (this one is visually hidden)
• changes the existing visually hidden heading "Attachments list" to "Media list" for consistency
• improves the singular / plural form translation of %s item selected by using wp.i18n.sprintf
• refactors the CSS of the media modal toolbar to take into account the new "Filter Media" heading

The CSS refactoring also improves the responsiveness of this part of the modal. There are still pre-existing issues, for example the date select is out of view at some viewports widths. This happens on all previous WordPress versions and fixing it would need a major refactoring of the media modal, which is out of the scope of this ticket.

Some testing would be nice :)
Please test on desktop at various viewports widths to trigger all the media queries.
Please test at least in Chrome and Firefox. Testing on Internet Explorer would be appreciated.

[afercia]

Latest patch – desktop

[afercia]

Latest patch – mobile

[afercia]

Note: on mobile, the "Media Types" heading becomes visually hidden (still available to assistive technologies) because at the same time the menu toggle button appears.

[afercia]

47610.3.diff​ improves the patch:

• makes sure the new headings are visible where they're expected to be visible
• visually hides the "Filter Media" in the Media Library grid
• QUnit tests were failing locally: added the i18n.js package and updated _wpMediaViewsL10n

[afercia]

Latest patch – desktop – with selection and visible sidebar

[melchoyce]

I think if we center "Media Types" this'll be good to get into trunk.

Desktop is good to go 👍

[afercia]

Thanks Mel. Feedback much appreciated.

[afercia]

47610.4.diff​ centers the mobile "Media Types" button and menu. See screenshot below.

The patch looks good to me. I'll quickly test on IE11 tomorrow then I'd like to commit if no objections.

[afercia]

Mobile: centered "Media Types" button and menu – closed and open

[afercia]

MInor: the "Media Types" text for the heading and mobile toggle button is appropriate for the main views. In the sub views is not the best text because the menu contains actions and not media types. See screenshot below.

I'd consider this a minor thing because the sub views are anyways in the context of an "Add Media", "Add Gallery", etc., flows. No objections to change that string if there are ideas for some better text.

[afercia]

Button text in a sub view.

[melchoyce]

Let's commit and iterate on copy in another patch.

Some copy ideas offhand:

• Settings
• [Gallery, Video, Audio, etc.] Settings
• [Gallery, Video, Audio, etc.] Actions
• More...

[afercia]

47610.5.diff​ addresses a minor issue for IE11 on small screens (the responsive view is unlike to be triggered in IE11 but it's good to improve anyways).

[afercia]

In 46375:

Accessibility: Media: Add more headings in the Media Modal.

Headings are the predominant mechanism for screen reader users to find information in a page. They also help all users to better identify the main sections of user interfaces.

• adds three new headings within the media modal
• improves plural form translation for "item selected" by using wp.i18n
• horizontally centers the media modal menu in the responsive view

Props kjellr, karmatosed, melchoyce, afercia.
See #47149.
Fixes #47610.

[afercia]

As per discussion on this ticket and on #47149 the "Media Types" heading text needs to be changed to take into account other types of available actions (e.g. Edit, Cancel) or actions plugins may add (e.g. Shortcode UI adds an "Insert Post Element" action).

Best option would be a heading text that clearly identifies what this UI section is about but that is also as generic as possible.

[afercia]

With 47610.6.diff​ I'd like to propose to change the "Media Types" heading text to "Actions".

Consequently, I changed also the visually hidden heading in the bottom toolbar from "Available actions" to "Selected media actions" to better distinguish from the other heading.

See screenshots (where I made the visually hidden heading temporarily visible to better illustrate).

[azaozz]

As per discussion on this ticket and on #47149 the "Media Types" heading text needs to be changed to take into account other types of available actions (e.g. Edit, Cancel) or actions plugins may add (e.g. Shortcode UI adds an "Insert Post Element" action).

Right. This is a contextual menu. By design contextual menus do not have titles or labels as they are always inconsistent/confusing. Please right-click in your browser window and see what is the title of the contextual menu you see? Now right-click on the desktop, and on a file on the desktop, etc. :)

In that terms neither "Media Types" nor "Actions" is appropriate there. Contextual menus do not have such labels as they are always inconsistent and often confusing. In this particular case the words "Media Types" do not describe the purpose of this menu, and the word "Actions" doesn't mean anything in that context and is completely redundant.

If this is needed for assistive technology to work better, it should be hidden from view. Then the hidden label/title should probably be changed to "Contextual menu" as this seems the best explanation there.

[afercia]

I kindly disagree. It's a shared opinion in the accessibility team that visible headings benefit all users. Also, a good UI should always serve the same content to all users.

The difficulty to find a proper heading for this UI section stems from the fact the UI is not well designed in the first place. "Contextual menus" are confusing for many users, not only for users with accessibility needs.

Please right-click in your browser window and see what is the title of the contextual menu you see? N

In my opinion this is an inappropriate comparison. Contextual menus on operating systems work very differently.

Also, the real need here is not the heading in relation of the menu. The main UI sections need to be identified with headings. RIght now they're... undefined: don't know / not sure what this section is about.

Given two entire WordPress teams, the design team and the accessibility team who specialize in Design, UI, UX, and accessibility, agreed on this change I'd have some troubles in sharing your point of view.

[azaozz]

Replying to afercia:

...Also, a good UI should always serve the same content to all users.

I think I see where the misunderstanding comes from. There are many places where hidden labels are added to help assistive technology work better. There "labels" are not appropriate for the visual design, they only make sense for assistive technology use. Also they can be "harmful" for the visual design as they break the semantics there and are confusing.

I agree that "a good UI should always serve the same content to all users". So how do you serve an image to users of assistive technology? You add an "alt" attribute. This attribute is not meant to be "always visible in all cases", making it visible is confusing for users that do not use assistive technology.

The difficulty to find a proper heading for this UI section...

This is not an UI section, this is a menu. On top of that it is a contextual menu. As such, a heading there is inappropriate. It breaks/diminishes the visual semantics.

Contextual menus on operating systems work very differently.

No. Contextual menus work pretty similarly in all cases, they change depending on context. Please point me to examples of contextual menus with heading in any application.

[azaozz]

Similarly to #34904 the code here was added far too late in the development cycle making it impossible to properly test and debug. These changes shouldn't have been committed during beta.

[afercia]

There are many places where hidden labels are added to help assistive technology work better. There "labels" are not appropriate for the visual design, they only make sense for assistive technology use.

Right. There are many visually hidden labels and headings in the admin and the reason why they are visually hidden it's because there was no consensus in changing the visual design. The accessibility team always recommended visible labels / headings because they benefit all users. I see in your feedback you seem to be very focused on screen readers. Accessibility is not just about screen readers. There are a multitude of different accessibility needs.

Also they can be "harmful" for the visual design as they break the semantics there and are confusing.

I'm not fully sure I understand what "visual semantics" is.

I agree that "a good UI should always serve the same content to all users". So how do you serve an image to users of assistive technology? You add an "alt" attribute. This attribute is not meant to be "always visible in all cases", making it visible is confusing for users that do not use assistive technology.

I have no objections :) The alt attribute is supposed to be visible only when the image is not visible (for any reason). I'm not sure how this relates to labels and headings that are supposed to be always visible.

This is not an UI section, this is a menu. On top of that it is a contextual menu. As such, a heading there is inappropriate. It breaks/diminishes the visual semantics.

Still not sure I understand what "visual semantics" is. Also, I kindly disagree: this is not a menu. Not a menu that triggers navigation to a different resource. The menu items are controls that update on the fly the content of the modal. Much like tabs that toggle the visibility of in-page content. In fact, they're now marked-up as ARIA tabs after #47149.

No. Contextual menus work pretty similarly in all cases, they change depending on context. Please point me to examples of contextual menus with heading in any application.

Of course I agree they both change depending on context. However, they do that in a very different way and the interaction is very different.

Contextual menus in operating systems (e.g. desktop right click, file manager right click): they are requested by the user after an intentional action. Users right click and they expect to get a menu because they learned that's the interaction. There's no need to identify them as a distinct UI section because they're not a real "section" of a composite UI in the first place.

These items in the left part of the media modal are not comparable to an operating system "context menu" in any way, at least to me :) They're part of a composite UI. They're always visible. Users are "forced" to always see them. They don't appear after a user action. They may change after a user action. Sometimes they change, sometimes don't. Regardless, this is a composite UI that is made of a set of discrete sections. Ideally, each section purpose needs to be clearly identified. In general, I think we (as developers) tend to look at a UI as "power users" greatly underestimating that many other users are really confused when things are not clearly identified.

To me, it's anyways a section of a composite UI and there are examples of "headings" used to identify similar sections e.g. the macOS finder, the Gnome file manager, and even the Google Chrome settings page.

[azaozz]

Replying to afercia:

I'm not fully sure I understand what "visual semantics" is.

Yeah, sorry, that's probably not the right term. What I mean by "visual semantics" is that you understand what you see on the screen. Basically if you look at a picture of a house and a tree, you "know" it is a house and a tree, if you look at a picture of a flower, you know it is a flower :)

Of course I agree they both change depending on context. However, they do that in a very different way and the interaction is very different.
...
These items in the left part of the media modal are not comparable to an operating system "context menu" in any way, at least to me :)

Right, this is not "hidden" like right-click menus in applications and operating systems. However:

1. This is a menu.
2. The content of the menu changes depending on context.

I'm not sure what else to call it except a "contextual menu" :)

Regardless, I can't find any examples in other applications (or web pages) that have menus with headings. So unless there are some, and unless the plan is to add headings to the main WP menu and to the admin bar menu, I think this change is inappropriate.

...Not a menu that triggers navigation to a different resource.

This is (technically) incorrect. Strictly speaking it triggers a request to the server and loads the new content in the modal.

I think I'm starting to understand what the problem is here. The problem is that "accessibility enhancements" are being applied by looking at the underlying (HTML) code, and not by looking at the elements on the screen. Then the accessibility recommendations are being applied to the code regardless of the UI elements that code represents. This seems like "the wrong way to do things" and often leads to inconsistencies in user experience for users of assistive technology.

In any case, calling a menu "not a menu" and adding a heading to it doesn't make sense. It was designed to be a menu, looks like a menu, and works like a menu.

That's also the reason there is no good title for it. Neither "Media Types" nor "Actions" describe what it is or what it does well. Even worse, perhaps in some cases that "title" can be confusing for some users.

[afercia]

I'm not sure what else to call it except a "contextual menu" :)

"Dynamic menu" :)

Regardless, I can't find any examples in other applications (or web pages) that have menus with headings.

In the previous comment I mentioned the macOS finder, the Gnome file manager, and even the Google Chrome settings page as quick examples.

This is (technically) incorrect. Strictly speaking it triggers a request to the server and loads the new content in the modal.

Yep, okay but not traditional navigation anyways. Not the same interaction and not the same feedback. The browser doesn't navigate to a new resource nor the media modal implements a routing system to emulate navigation. Technically, these are buttons that trigger an AJAX request to fetch data and inject them dynamically within the current page together with a mix of JS and HTML. To me, that's not navigation so this is not a navigation menu. I could agree it's an "actions menu".

Then the accessibility recommendations are being applied to the code regardless of the UI elements that code represents. This seems like "the wrong way to do things" and often leads to inconsistencies in user experience for users of assistive technology.

I'm sorry but this sounds very arguable to me :) And sounds like a lack of a full understanding of what accessibility is.

[afercia]

47610.7.diff​ adds context and translator comment.

[afercia]

In 46488:

Accessibility: Media: Improve the new Media Modal headings text.

See #47610.

[azaozz]

Replying to afercia:

"Dynamic menu" :)

Hahaha, ok, you're right. That's a better way to describe it: dynamic menu (that may change depending on context) :)

Yep, okay but not traditional navigation anyways. Not the same interaction and not the same feedback. The browser doesn't navigate to a new resource nor the media modal implements a routing system to emulate navigation.

Hm, ok, but how emulating navigation would change how that modal is used or how it behaves? Don't think it would?

I'm sorry but this sounds very arguable to me :)

Ah, perhaps I'm misunderstanding something. Isn't that what you meant by "it may look like a menu but is in fact tabs"?

And sounds like a lack of a full understanding of what accessibility is.

As far as I understand "accessibility" is "the design of products, devices, services, or environments so as to be usable by all people, including people with disabilities." Is that incorrect?

Anyway, the fact remains there is no good "heading" for that menu. Isn't adding an inappropriate, perhaps misleading "heading" there going to cause accessibility problems, not "fix" them? Looking at the MacOS, Gnome, etc. examples, they seem to have menu sub-section headings, "Favourites", "Devices", etc. not a heading for the whole menu? "Actions" doesn't really mean anything there :(

[sabernhardt]

@afercia Thanks for the text updates and translator context.

@melchoyce I'll defer to others' decisions regarding the all-caps heading style you mentioned on ticket #47179 [my fault for confusing the tickets].

Will we have another meeting or bug-scrub before RC1 (on Core, Media or another Slack channel) to reach a final verdict on whether the Actions heading is there/visible/restyled in 5.3.0?

I see these 4 options (in order of my preference, FWIW):

1. Leave the heading visible as it is now (after r46489),
2. Visually hide the element with the screen-reader-text class,
3. Use the all-caps style for consistency, or
4. Remove that heading entirely.

[desrosj]

RC1 is set to be packaged in a few hours as soon as a few more blockers are cleared up.

Can someone please briefly summarize the status? Are these changes production ready for the world? Is there anything else required for this ticket? If not, can this be closed out in favor of follow up tickets?

[afercia]

Thanks @desrosj. This comment from #47149 applies: https://core.trac.wordpress.org/ticket/47149#comment:90

Sorry but the two tickets have been used interchangeably for discussing the new headings. Actually, the ticket for the headings is this one. Will move the patch uploaded on #47149 here.

[afercia]

On #47149 some concerns were expressed about the "prominence" of the new heading in the left sidebar. Happy to implement any design feedback to make it less prominent. Some feedback from the design team would be appreciated, otherwise I guess we can iterate in the next release cycle.

If I can suggest a possible option:

• not sure why the active items in the left sidebar are black in the first place
• interactive elements in WordPress are blue, that's a well established convention
• I'd like to propose to keep the active item blue (and bold)
• Unbold the new headings

This way, the heading would be less prominent. See attached screenshot. Please just let me know if there's any objection to commit. Thanks.

[melchoyce]

The item is grey because once it's active, it's not really selectable anymore. Clicking it again doesn't do anything.

At this point, I think we should probably leave as-is and think about it more systematically ​as we explore new type patterns in the future. We're introducing a lot of (necessary) exceptions this release to balance all the changes we're making and I think it might be better to deal with awkwardness for another release or two instead of making more.

[azaozz]

Replying to sabernhardt:

I see these 4 options (in order of my preference, FWIW):

1. Leave the heading visible as it is now (after r46489),
2. Visually hide the element with the screen-reader-text class,
3. Use the all-caps style for consistency, or
4. Remove that heading entirely.

Thanks for summarizing the discussion about this heading.

As far as I see 2 is the proper solution here if that heading is needed to help screen reader users. Usually menus do not have (visible) headings as they do not serve any purpose. Examples are the other menus in WP, and in pretty much all applications I've seen.

If that heading is not needed for screen readers, 4 would be most appropriate.

[afercia]

The item is grey because once it's active, it's not really selectable anymore. Clicking it again doesn't do anything.

@melchoyce yep, clicking it doesn't do anything visually because the related content is already loaded. However, it is still focusable and can be navigated with the keyboard so it is interactive :)

[melchoyce]

However, it is still focusable and can be navigated with the keyboard so it is interactive :)

Semantically, yeah, but I think most folks are used to "active" menu items not looking like links while they're active.

[afercia]

I think most folks are used to "active" menu items not looking like links while they're active

Sure, agreed. I'd say it just needs a different active style. It is still bold now.

As far as I see 2 is the proper solution here if that heading is needed to help screen reader users. Usually menus do not have (visible) headings as they do not serve any purpose.

@azaozz I think the lack of consensus is exactly on this point :) For accessibility, visible headings are recommended.

There's also a nice WCAG tutorial to explain how to markup different regions of web pages *and applications*.

Page Regions
Mark up different regions of web pages and applications, so that they can be identified by web browsers and assistive technologies.
​https://www.w3.org/WAI/tutorials/page-structure/regions/#navigation

There's a specific example for navigation that uses a visible heading within a <nav> element.

In our case we can't use a <nav> element because this isn't exactly a navigation menu. The heading is still necessary though.

Aside: reminder that also the ATAG (Authoring Tools Accessibility Guidelines) refer to WCAG for web-based authoring tool user interfaces.

[melchoyce]

In our case we can't use a <nav> element because this isn't exactly a navigation menu.

Total aside question for my own learning: why is this? What's the difference between this menu and a navigation menu?

[afercia]

What's the difference between this menu and a navigation menu?

This menu has been changed to an ARIA tabs interface in #47149. The ARIA tabs pattern is better for content that gets updated dynamically. There's no real, traditional "navigation" here as in a classical page reload. The browser and, consequently, assistive technologies are unaware a content update occurred. The ARIA tabs pattern allows to indicate what the selected item is and also implements arrows navigation on the items so that is possible to tab directly from the active item to the active content.

[melchoyce]

Thanks, I appreciate the explanation.

[afercia]

Removing the i18n-change keyword as the string change was committed in [46488].

[azaozz]

I think the lack of consensus is exactly on this point :) For accessibility, visible headings are recommended.

Yes, I understand. So to enforce that visible heading the argument here is that this is not really a menu. It doesn't matter that it was designed to be a menu, was used as a menu, looks like a menu, and works as an application menu :)

So there ATAG recommends that all menus must have headings? And why introduce the inconsistency, as that will be the only menu in WP that has a heading :)

Anyways, lets review this in 5.4. Time is running out as this change was introduced far too late in the dev. cycle to have the time to research and review it properly.

Closing as fixed for now as there are other, unrelated changes on this ticket. It is unfortunate that this wasn't reviewed well.

[afercia]

So there ATAG recommends that all menus must have headings?

WCAG recommends that page regions (in our case UI sections) are identified. There are techniques for that and one of them is by using headings.

[afercia]

Then the accessibility recommendations are being applied to the code regardless of the UI elements that code represents. This seems like "the wrong way to do things" and often leads to inconsistencies in user experience for users of assistive technology.

I'm sorry but this sounds very arguable to me :) And sounds like a lack of a full understanding of what accessibility is.

As far as I understand "accessibility" is "the design of products, devices, services, or environments so as to be usable by all people, including people with disabilities." Is that incorrect?

Sure that is, though today it's preferable to say "regardless of the ability level".

I didn't meant that though. In this part: "Then the accessibility recommendations are being applied to the code regardless of the UI elements that code represents" seems that UI elements should take precedence on the code and the code should just do its best to adapt to the visuals. This process isn't ideal under many aspects and it's what got us here, where the general accessibility of the WordPress admin isn't great.

It should be quite the opposite :) Code needs to convey meaning and UI elements should adapt to represent that meaning at their best. Web standards and accessibility guidelines should be implemented from the very beginning of any design process and on top of that progressive enhancement can be used to build modern, beautiful, interfaces.

[azaozz]

Replying to afercia:

Sure that is, though today it's preferable to say "regardless of the ability level".

Heh, sorry, the wording came petty much straight out of Wikipedia: ​https://en.wikipedia.org/wiki/Accessibility.

Code needs to convey meaning and UI elements should adapt to represent that meaning at their best. Web standards and accessibility guidelines should be implemented from the very beginning of any design process and on top of that progressive enhancement can be used to build modern, beautiful, interfaces.

Right, exactly. At this point this is mostly a "principle" question.

• This used to be an "application menu".
• It still fulfills the role of "application menu".
• However the underlying code for it was changed to be "not-a-menu". The reason for the change was that "a menu must trigger navigation or it is not a menu".
• There are several other "application menus" in WP that do not trigger navigation. In that terms this menu is now inconsistent.

So, the code for this UI element was changed to convey different (incorrect?) meaning, and then the UI element had to also change because the code was changed. This was done regardless of the fact that this UI element is (still) being used as a menu.

In coding terms this is not a "progressive enhancement", but a "regression".

[afercia]

Looks like we agree we disagree :) Aside: this conversation would be more appropriate on #47149, where the menu markup was changed to an ARIA tabs pattern while this ticket is about headings and naming.

I'd agree it's a principle question at this point but it's always good to have a constructive and clarifying conversation. :)

This used to be an "application menu".

The term "menu" is probably a bit too generic and often used to identify different things in software.

The ARIA specification defines ​role=menu as "a list of common actions or functions, presented in a manner similar to a menu on a desktop application". This seems to exclude "navigation menus" for which the role=navigation should be used.

Instead, the ARIA Authoring Practices refer a bit interchangeably to menus as "navigation" or "action" menus, see for example ​https://www.w3.org/TR/wai-aria-practices-1.1/#menubutton, which seems to contradict the ARIA spec.

Regardless of what the various specifications say, we can probably use a some good common sense and refer to a couple well established patterns:

• Navigation menu: made of items that behave as links.
• Action menu: made of items that trigger actions or commands (for example: align left, align center...).

Thinking at the media modal menu, none of the two patterns above seems appropriate to me. It's not a navigation because the browser doesn't navigate to a new page: the interaction and feedback are different from a real navigation. There's no routing, no browser history, no document title update... nothing that resembles to a real navigation. No specific action or command is executed on the edited object as well so I wouldn't call this an "action menu".

Instead, what these menu items actually do is making some content appear dynamically in the right panel.

If I had to expand the menu items text with some more context, I'd say something along the lines of:

• View the Add Media panel (or "open" the Add Media panel)
• View the Create Gallery panel
• etc.

Because that's what the menu items do: I click on them and I can access a new UI for a specific task.

Basically, these menu items reveal new content. There's an established, accessible, design pattern for that: the ARIA tabs pattern. It's the only pattern I can think of to properly communicate the semantics of this "menu".

Also, the tabs pattern is used everywhere in operating systems: it's a well established interaction pattern users and assistive technologies know and are able to interact with.

The previous implementation was far from ideal. This "menu" used to be made of links with an href value that technically was an "incomplete URL fragment identifier" like this:

<a href="#" class="media-menu-item">Create Gallery</a>

These menu items were totally unsemantic, perceived as links while not real links, and the expected interaction mismatched the actual interaction.

Links with a href="#" are embarrassing in 2019. They're an old, very wrong, practice.

In coding terms this is not a "progressive enhancement", but a "regression".

Frankly, I'm not sure how removing old, bad, code and introducing semantic, accessible, well established patterns can be called a "regression".

I do agree there's a problem with the naming. As commented previously, I'd appreciate any suggestion for a better name. This doesn't negate that the new implementation is far better than the previous one.

There are several other "application menus" in WP that do not trigger navigation

Totally right :) There are still a lot of places in core that need improvements. Any help there would be greatly appreciated.