Add H1 page titles to login/registration forms for accessibility

Context

While working on login form design changes for another petition and discussing accessibility, it dawned upon me that current ClassicPress (and WordPress) login, registration, and lost password pages are missing H1 page titles.

The H1 is wasted on the logo, and the title is technically the <p> text styled as an alert box.

WCAG requires <title> but it is a best practice for the <title> to match top heading on the page, usually marked as H1.

A quick look at some of the largest companies’ login forms - Google, Amazon, Apple, US government - all have H1 page titles.

Possible implementation

First, the logo should probably be wrapped in a <div> with the appropriate class.
Second, add H1 titles using the same text string that’s used to generate <title> for these pages. This will take care of the translations too, no new text.

  • Log In
  • Lost Password
  • Registration Form

This uses the updated form design from the other petition but can be implemented on the current forms/pages.

Will you be able to help with the implementation?

I may be able to help. Maybe as part of the updated form design petition.

1 Like

Good point! All the custom login pages I’ve built do something like this.

2 Likes

There is an HTML5 solution for this as an ARIA.

<div role="heading" aria-level="1">This is a main page heading</div> added just after any text will tell screen-readers and tags (heading tags not inside a header) that this is a level 1 heading. It is adviced to use role= in the same tag; typically span or div tags are best.

The aria-level attribute specifies the heading level in the document structure. If no level is present, a value of 2 is the default.

WAI-ARIA Roles can be found here: WAI-ARIA Roles - Accessibility | MDN

1 Like

Thanks for sharing. Yes, ARIA can help fix certain issues but the first rule of ARIA is not to use it. It’s better to use built-in HTML features than to repurpose others with ARIA.

4 Likes

Understood. Was not aware of rule #1… thanks for that. Maybe solution is plugin territory so that other “login page” plugins can add elements freely?

If this is implemented, the hooks would remain. So plugins trying to customize login page would still be able to do what they need to do. This would make core more accessible out of the box.