Try editor heading

[jasmussen]

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.

[afercia]

It's an improvement: at least, it would help screen reader users. I still think this main h1 should be visible though, to give a clear context to everyone about what they're editing.
Currently, there's no indication if I'm editing a post, a page, or maybe a CPT testimonial, a project, a product...

Also, at this point the post title shouldn't be a h1 wrapping a textarea. We're in an editing context and the main topic of the page is "Edit post", not the post title. I've heard there were plans to change the post title in a block, not sure about the progress there.

[jasmussen]

There are certainly two aspects to #503, one is the screen reader label, the other I would suggest is a design consideration. These two can absolutely be the same, and commonly are, but I would like to explain why such a page title has not been part of the design yet. As you read that, it doesn't mean it can't be — we've already gone through many iterations of the editor bar as well as the design, so it's not off the table.

In any case, the reason I did not include that title, is that we have the following interface to indicate visually what you'r looking at:

The purpose here is to free up as much space as possible for the editing canvas, and minimizing UI at the same time.

How would you feel about trying this approach for now (given corrections so the actual post type is correctly output and the whole thing is translatable)? As we continue to improve the screen reader experience and testing the UI, we'd then be able to better decide whether an explicit page title is necessary or not (and if it is, we can easily reuse the code).

An alternate approach is to show the CPT in the save status indicator:

So "Saved Page" instead of "Saved", etc. This would be in addition to the <h1>.

Thoughts?

[jasmussen]

Oh also, can you elaborate on the following?

Also, at this point the post title shouldn't be a h1 wrapping a textarea. We're in an editing context and the main topic of the page is "Edit post", not the post title. I've heard there were plans to change the post title in a block, not sure about the progress there.

What would mitigate this? Should the post title not be a h1?

[afercia]

The purpose here is to free up as much space as possible for the editing canvas, and minimizing UI at the same time.

I understand what the purpose is 🙂 I guess the point is exactly this: we're omitting a functional feature that's useful for all users, not just screen readere users, for the sake of visual "cleanliness".

While the admin menu gives some indication when it's opened, I'd like to remind it can be collapsed based on user settings and it's completely hidden in the responsive view:

In these cases there's really no indication of what is being edited.

I'd certainly go for the visually hidden h1 for now, as it is an improvement. I'd recommend to keep the door open to a visible heading though. Worth considering this hi doesn't necessarily need to look like "big text": it can be styled.

As per the post title being a h1: a web page should have just one h1, and it should indicate what the page is about. We're in an editing context here, this is not the frontend. So when users land on the edit post page, the question the h1 should answer is:

• what this page is about?
• answer: this page is about editing a post (or page etc.)

Instead, the post title answer this question only in the frontend, where it is actually the main topic fo the page. In the backend, it doesn't. Think of a post with a title "Hello world". When you're editing in the backend, would "Hello world" identify the topic/purpose of the page? Certainly not, as the main topic / purpose of the page is about editing a post so the main h1 should say "Edit post" or "Edit post Hello World".

Also, from a semantic perspective, in an editing context the post title doesn't need to be a heading in the first place.

[jasmussen]

Great thoughts, thanks for that.

Instead, the post title answer this question only in the frontend, where it is actually the main topic fo the page. In the backend, it doesn't. Think of a post with a title "Hello world". When you're editing in the backend, would "Hello world" identify the topic/purpose of the page? Certainly not, as the main topic / purpose of the page is about editing a post so the main h1 should say "Edit post" or "Edit post Hello World".

Also, from a semantic perspective, in an editing context the post title doesn't need to be a heading in the first place.

So you're saying that one solution could be that the h1 could be the screen reader text (visible or otherwise), and the post-title could be a h2 in the editing context and output a h1 in the frontend context? Just want to make sure I read you right.

[afercia]

the h1 could be the screen reader text (visible or otherwise)

yes

and the post-title could be a h2 in the editing context and output a h1 in the frontend context?

no: in the editing context it shouldn't be a heading at all. Instead, it should be an editable field (textarea or input or editable if it will be changed in a block)

[jasmussen]

I pushed a change to make the post-title component use a textarea wrapped in a div, instead of a textarea wrapped in a h1. Does that address the 2nd item?

[afercia]

Looks good to me! (maybe the div can be removed entirely?)

[afercia]

Worth noting the other headings level should be reviewed, as at the moment there's a skipped level:

Please let me know if you want me to open a new issue.

[jasmussen]

(maybe the div can be removed entirely?)

I tried, but we can't style the textarea alone to sufficiently look like a block, and given it might one day be a block, seemed like it would be worth to keep a wrapping element.

Worth noting the other headings level should be reviewed, as at the moment there's a skipped level

I can make those h2's, I guess that would help?

[afercia]

I can make those h2's, I guess that would help?

That would be great.

[jasmussen]

Changed the sidebar headings. Does this fix #2024?

[jorgefilipecosta]

Code changes look good to me. I tested this and I did not found any regression or design changes. If this change addresses the a11y issues it is good to go.

[afercia]

@jasmussen thanks for working on this! I've realized that also other headings need to be bumped up by one level. For example, expanding "Categories & Tags" reveals two h4 headings that should be now changed in h3 😬
Not sure if there are other headings in the sidebar that would need the same treatment.

[jasmussen]

Good catch. I think I fixed it above, but I also went through a lot of the block settings which were H3s and should presumably H2s, so changed that.

I appreciate the previous review, @jorgefilipecosta, but would appreciate a second pair of eyes before I merge as that last commit was sllliiiightly big. Thanks so much.

[pento]

Code changes look good to me.

[jasmussen]

Merged this a bit too quickly, so reverted. Going to revisit and make sure "Edit Post" is also both translatable and contextual (i.e. Edit Page, Edit [CPT]) etc.