Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add headings for the Editor screen main sections #503

Closed
afercia opened this issue Apr 24, 2017 · 11 comments · Fixed by #3937 · May be fixed by MaxMood96/gutenberg#3 or yassine4999/gutenberg#2
Closed

Add headings for the Editor screen main sections #503

afercia opened this issue Apr 24, 2017 · 11 comments · Fixed by #3937 · May be fixed by MaxMood96/gutenberg#3 or yassine4999/gutenberg#2
Assignees
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Priority] High Used to indicate top priority items that need quick attention [Type] Task Issues or PRs that have been broken down into an individual action to take
Milestone

Comments

@afercia
Copy link
Contributor

afercia commented Apr 24, 2017

Splitting this out from #467

In the current plugin implementation, the Editor screen has no headings at all.

screen shot 2017-04-25 at 00 01 36

It misses a main H1 and maybe it could benefit from some H2 used to identify the main UI sections (to evaluate, this depends on the actual grouping of the main controls).

Headings are used for content navigation and allow screen reader users to "jump" from a section to another one. That's clearly explained on https://make.wordpress.org/core/2015/10/28/headings-hierarchy-changes-in-the-admin-screens/ which also illustrates all the work done about headings in the last releases.
A proper headings hierarchy is also a WCAG requirement.

I'm not a designer, so I'd leave the visual part to designers 🙂 For the accessibility part, I'd propose to discuss this issue in the next accessibility meeting on Slack.

@afercia afercia added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Apr 24, 2017
@jasmussen
Copy link
Contributor

We haven't designed a spot for this heading, so the idea of adding it as invisible screen reader text appeals to me. What tool would you recommend we use when going about this?

@jasmussen jasmussen added the [Type] Task Issues or PRs that have been broken down into an individual action to take label Apr 26, 2017
@afercia
Copy link
Contributor Author

afercia commented Apr 28, 2017

I'd also note that, currently, the main heading is the only piece of information that says to user what they're editing: post, custom post, or page:

post

project

page

@afercia
Copy link
Contributor Author

afercia commented Apr 28, 2017

What tool would you recommend we use when going about this?

To hide text in a way that's still accessible, WordPress uses the screen-reader-text CSS class. However, I'd consider to make the heading visible as per the consideration in my last comment.

P.S. let's try to separate the visual look of headings from their semantics. Headings don't necessarily need to be "big" 🙂

@mapk
Copy link
Contributor

mapk commented Apr 28, 2017

I'm moving my comment from #467 , sorry for derailing the other ticket.

heading

I've added the word "Editor:" to the Toolbar. That word could be an H1, but styled to match the surrounding interface. The dropdown "Visual" would not be part of it, and not affect the H1. Seems like it might fit nicely with tab order too.

Any thoughts?

@jasmussen
Copy link
Contributor

I really think we should explore the hidden section title here. In my mind, the active section is already highlighted both by the page <title>, as well as the selected item in the sidebar. I don't know how you can end up on this page, without knowing what it's all about. In addition to this, the sidebar button label will indicate whether you're editing a post, page, or custom post type — "Page Settings".

@afercia
Copy link
Contributor Author

afercia commented Apr 28, 2017

I think there's the risk of underestimating the potential confusion for users here 🙂 Having a cleaner UI is a win for everyone. But, as I see it, this shouldn't happen at the cost of removing important information.

I still think there should be some sort of indication about the "what", together with re-considering the ordering and grouping of controls. I'd also like to see this being discussed by the design team and be open to the community feedback. As far as I know, a real, broad, discussion hasn't happened yet.

One more potential issue is about controls that use icons only. Icons don't have a universal meaning. I don't fully understand why some controls have only icons and other have icons plus some visible text. What't the reasoning behind that?

Also to consider, there are functions in WP that provide labels to be used by CPTs for this screen. Integrating such a change wouldn't be so easy.

@joyously
Copy link

I don't know how you can end up on this page, without knowing what it's all about.

Are you thinking of users that only ever use one browser window? There are a lot of users that always use more than one window, especially when copying. In a scenario that involves combining content from multiple pages or custom posts into a different post, there could be several windows open on editor pages that all look similar (due to copied content). How would that user tell them apart easily?

@afercia
Copy link
Contributor Author

afercia commented Apr 29, 2017

In the current WP editor, one of the most difficult tasks for screen reader users is navigating from the editable area to the editor toolbar. There is the TinyMCE shortcut Alt+F10, maybe not so intuitive. Instead, headings are the predominant mechanism for finding content, together with an increasing knowledge and use of ARIA landmark regions.

I've played a bit with this, and a few headings could greatly help, for example using Safari + VoiceOver:

headings test

It would be a matter of just a few keypresses to find the toolbars or skip the toolbars and go straight to the editor (headings text is just for testing purposes, worth considering a better wording).

@afercia
Copy link
Contributor Author

afercia commented Aug 3, 2017

To recap the headings situation as of August 3rd:

screen shot 2017-08-03 at 11 13 39

The headings in the first group in the screenshot above are all in the post content. The post title is always presented as H1.

The headings in the second group are in the editor sidebar and they start with a H3 level.

Right now, the Gutenberg screen is the only screen in WordPress that doesn't have a main H1 heading to identify the purpose of the page. In the classic editor, this is done with the h1 "Edit Post", "Edit Page", "Edit {custom post type name}".

@afercia afercia added the [Priority] High Used to indicate top priority items that need quick attention label Aug 29, 2017
@afercia
Copy link
Contributor Author

afercia commented Aug 29, 2017

Marking with the high priority label to indicate it's an a11y priority. The Gutenberg page is the only one in WordPress that doesn't have a proper heading hierarchy starting with an H1 that indicates what the page is about.

@karmatosed karmatosed added this to the Beta, Needs to happen milestone Oct 4, 2017
@afercia
Copy link
Contributor Author

afercia commented Oct 23, 2017

Slightly unrelated but also the document title should be fixed:

old editor:
<title>Edit Post &lsaquo; WordPress Develop &#8212; WordPress</title>

(or "Edit Page" etc, depending on what's being edited)

Gutenberg:
<title>Welcome to the Gutenberg Editor | Add New Post ‹ WordPress Develop — WordPress</title>

@jasmussen jasmussen self-assigned this Dec 4, 2017
jasmussen pushed a commit that referenced this issue Dec 4, 2017
This is a work in progress, which adds a page heading for screen readers. @afercia can you take a look and see if this mitigates #503?

If yes, then we'd need to wrap the actual label into a function so it not only outputs the right post type, but indeed is translatable.
jasmussen pushed a commit that referenced this issue Dec 4, 2017
This adds a page heading for screen readers. If this mitigates #503, then we'd want to make sure that the correct post type is output, and the text is translatable.
jasmussen pushed a commit that referenced this issue Dec 12, 2017
This is round 2 of #3801.

It mitigates/fixes #503 and fixes #2024.

What remains to be done in this branch is:

- Make sure the text is translatable, right now it's hardcoded to "Edit Post"
- Make sure the text is contextual (so it shows Edit Page, Edit CPT etc)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Priority] High Used to indicate top priority items that need quick attention [Type] Task Issues or PRs that have been broken down into an individual action to take
Projects
None yet
5 participants