WordPress.org

Make WordPress Core

Opened 4 months ago

Closed 33 hours ago

Last modified 32 hours ago

#47610 closed defect (bug) (fixed)

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

Reported by: afercia Owned by: afercia
Milestone: 5.3 Priority: normal
Severity: normal Version:
Component: Media Keywords: needs-post-mortem has-screenshots has-patch
Focuses: ui, accessibility, javascript Cc:
PR Number:

Description

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:

http://cldup.com/tFz6B5nj3j.png

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.

Attachments (17)

media headings.jpg (206.8 KB) - added by afercia 8 weeks ago.
Some sections of the media modal dialog are not identified by a heading
47610.diff (4.5 KB) - added by afercia 4 weeks ago.
47610.2.diff (7.1 KB) - added by afercia 2 weeks ago.
47610 01.jpg (297.0 KB) - added by afercia 2 weeks ago.
Latest patch – desktop
47610 02.jpg (159.3 KB) - added by afercia 2 weeks ago.
Latest patch – mobile
47610.3.diff (20.4 KB) - added by afercia 2 weeks ago.
47610 03.jpg (148.4 KB) - added by afercia 2 weeks ago.
Latest patch – desktop – with selection and visible sidebar
47610.4.diff (20.9 KB) - added by afercia 2 weeks ago.
47610 final 01.jpg (194.8 KB) - added by afercia 2 weeks ago.
Mobile: centered "Media Types" button and menu – closed and open
47610 final 01 media types text.jpg (46.9 KB) - added by afercia 2 weeks ago.
Button text in a sub view.
47610.5.diff (21.2 KB) - added by afercia 2 weeks ago.
47610.6.diff (1.2 KB) - added by afercia 6 days ago.
47610.6.01.png (391.9 KB) - added by afercia 6 days ago.
47610.6.02.png (235.4 KB) - added by afercia 6 days ago.
47610.7.diff (1.3 KB) - added by afercia 2 days ago.
47610.8.diff (484 bytes) - added by afercia 38 hours ago.
47610 example.png (143.5 KB) - added by afercia 37 hours ago.

Download all attachments as: .zip

Change History (90)

#1 @afercia
4 months ago

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

This ticket was mentioned in Slack in #core-media by karmatosed. View the logs.


2 months ago

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


2 months ago

#4 @karmatosed
2 months ago

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

#5 @afercia
8 weeks ago

@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
8 weeks ago

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

#6 @kjellr
7 weeks ago

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

https://cldup.com/GkPEWPLOmg.jpg

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?

https://cldup.com/0cpzogdiu4.jpg

  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"

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


7 weeks ago

#8 @afercia
7 weeks ago

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

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


7 weeks ago

#10 @afercia
7 weeks ago

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

#11 @kjellr
5 weeks ago

  • Owner set to karmatosed
  • Status changed from new to assigned

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

@afercia
4 weeks ago

#12 @afercia
4 weeks ago

  • Keywords has-patch added

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:

http://cldup.com/DH6wgbuNjw.jpg

#13 @afercia
4 weeks ago

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.

#14 @karmatosed
4 weeks ago

  • Owner karmatosed deleted

#15 @karmatosed
4 weeks ago

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.

#16 @karmatosed
4 weeks ago

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?

#17 @afercia
4 weeks ago

@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.

Last edited 4 weeks ago by afercia (previous) (diff)

#18 @karmatosed
4 weeks ago

  • Keywords needs-design added; needs-design-feedback removed

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

#19 @karmatosed
4 weeks ago

  • Owner set to karmatosed

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


4 weeks ago

#21 @karmatosed
4 weeks ago

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:

http://cldup.com/lGlo2DbbP0.png

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:

http://cldup.com/xfrMKEBYpS.png

#22 @kjellr
4 weeks ago

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:

https://cldup.com/FOho-Gqat--2000x2000.png

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"?

#23 @afercia
3 weeks ago

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.

#24 @kjellr
3 weeks ago

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?

https://cldup.com/BTt8Uh0J3X-3000x3000.png

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.

https://cldup.com/lIBaVlaJEX-3000x3000.png

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.

This ticket was mentioned in Slack in #design by afercia. View the logs.


3 weeks ago

#26 @karmatosed
3 weeks ago

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.

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


3 weeks ago

#28 @afercia
3 weeks ago

@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? :)

#29 @karmatosed
3 weeks ago

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
2 weeks ago

#30 @afercia
2 weeks ago

  • Keywords needs-design-feedback added; needs-design removed

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
2 weeks ago

Latest patch – desktop

@afercia
2 weeks ago

Latest patch – mobile

#31 @afercia
2 weeks ago

  • Keywords commit added

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.

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


2 weeks ago

@afercia
2 weeks ago

#33 @afercia
2 weeks ago

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
2 weeks ago

Latest patch – desktop – with selection and visible sidebar

This ticket was mentioned in Slack in #design by afercia. View the logs.


2 weeks ago

#35 @melchoyce
2 weeks ago

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

Desktop is good to go 👍

#36 @afercia
2 weeks ago

  • Keywords needs-design-feedback commit removed

Thanks Mel. Feedback much appreciated.

@afercia
2 weeks ago

#37 @afercia
2 weeks ago

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
2 weeks ago

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

#38 @afercia
2 weeks ago

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
2 weeks ago

Button text in a sub view.

#39 @afercia
2 weeks ago

  • Keywords commit added

#40 @melchoyce
2 weeks ago

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
2 weeks ago

#41 @afercia
2 weeks ago

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

#42 @afercia
2 weeks ago

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

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.

#43 @afercia
2 weeks ago

  • Keywords commit removed

This ticket was mentioned in Slack in #core-media by mike. View the logs.


7 days ago

#45 follow-up: @afercia
6 days ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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
6 days ago

#46 @afercia
6 days ago

  • Keywords i18n-change added

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

Last edited 6 days ago by afercia (previous) (diff)

@afercia
6 days ago

@afercia
6 days ago

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


6 days ago

#48 in reply to: ↑ 45 @azaozz
5 days ago

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.

Last edited 5 days ago by azaozz (previous) (diff)

#49 follow-up: @afercia
5 days ago

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.

#50 in reply to: ↑ 49 @azaozz
4 days ago

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.

#51 @azaozz
4 days ago

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.

#52 @azaozz
4 days ago

  • Keywords needs-post-mortem added

#53 follow-up: @afercia
3 days ago

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.

#54 in reply to: ↑ 53 @azaozz
2 days ago

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.

Last edited 2 days ago by azaozz (previous) (diff)

#55 follow-up: @afercia
2 days ago

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
2 days ago

#56 @afercia
2 days ago

47610.7.diff adds context and translator comment.

#57 @afercia
2 days ago

In 46488:

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

See #47610.

#58 in reply to: ↑ 55 @azaozz
2 days ago

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 :(

#59 follow-up: @sabernhardt
2 days ago

@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.

#60 @desrosj
38 hours ago

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?

#61 @afercia
38 hours ago

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.

Last edited 33 hours ago by SergeyBiryukov (previous) (diff)

@afercia
38 hours ago

#62 @afercia
37 hours ago

  • Owner changed from karmatosed to afercia
  • Status changed from reopened to assigned

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.

#63 @melchoyce
36 hours ago

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.

#64 in reply to: ↑ 59 @azaozz
36 hours ago

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.

Last edited 36 hours ago by azaozz (previous) (diff)

#65 @afercia
36 hours ago

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

#66 @melchoyce
36 hours ago

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.

#67 @afercia
36 hours ago

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.

#68 @melchoyce
36 hours ago

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?

#69 @afercia
35 hours ago

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.

#70 @melchoyce
35 hours ago

Thanks, I appreciate the explanation.

#71 @afercia
33 hours ago

  • Keywords i18n-change removed

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

#72 @azaozz
33 hours ago

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

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.

Last edited 32 hours ago by azaozz (previous) (diff)

#73 @afercia
32 hours ago

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.

Note: See TracTickets for help on using tickets.