Use h2 for error summary heading #510
Conversation
The error summary uses an additional h1 on top of the main h1 of the page. This is changing that to an h2. Although it's neither inaccessible, unsemantic or wrong to use two h1s on a page in a case like this, it causes friction with accessibility auditors, the good practice not to have two h1s per page, generally people who disagree with this from a semantic point of view and people spending time responding to such reports repeatedly. This was user-tested with a couple of screen reader users, as they would be the only ones affected by this change, and the change of heading hierarchy didn't cause any problems.
|
@selfthinker Just to confirm...the heading changes to a h2 but the summary box stays above the h1. Is that right? |
|
@stevenaproctor, yes, that's right. I explain the reason for that in the "What about having the summary after the main heading?" section of the description above. |
|
According to this, W3C are okay with non-hierarchical headings. I think it's important that when user presses Continue, focus moves to the error summary (if any) so that things are read out in an order which makes sense. I tested this in Chrome and the focus appears to be working correctly (I'm currently on a machine with very limited capabilities, hence there's limits to what I can test). |
|
@selfthinker Thanks for clarifying. I thought WCAG 1.3.1 and 2.4.10 said headings had to be in order without skipping levels. Putting a h2 before a h1 would skip the h1 and break the logical structure. I think this is why it is a h1 now. I got this from G141. |
|
Those two success criteria you mentioned don't say anything about headings needing to be in order. That might be in a different criterion, not sure. It might also just be an interpretation of those criteria. I think what is most important is that there is a structure and that the structure is consistent and therefore predictable. As I mentioned before, the problem is that HTML only knows how to do structure of web documents and not web sites. For example, we have headings in the footer which are structurally underneath the h1 but they don't relate to the document but to the website, so that hierarchy is strictly speaking already wrong (and not possible to get right). The W3C's Web Accessibility Tutorials have two examples on how to go about heading levels in a site structure with the markup possibilities we currently have. And one of those examples uses what I have proposed here, i.e. an h2 before the h1. (The other one makes the main heading an h2.) |
|
G141 says "To facilitate navigation and understanding of overall document structure, authors should use headings that are properly nested (e.g., h1 followed by h2, h2 followed by h2 or h3, h3 followed by h3 or h4, etc.)." I just wanted to make sure putting the h2 first would not confuse people, especially as the summary box is in the main part of the page, not a sidebar or navigation. |
|
I see no issue with having a H2 above the H1; this is a relatively common pattern I encounter. particularly when hidden headings are used to add context to navigation regions on the page, they will often appear hierarchically above the main h1 heading. is the Errror also incorporated into the page title as well? One concern may be that screenreader users will either jump to the main landmark, or the h1 heading, thus missing the error text. If the Error is also alerted in the page title, this would be a prompt for those users to investigate the page and discover the errors. Other than that, I would not fail a page for simply having a h2 above a h1 - as others have commented, this does not fail WCAG 2, nor does it fail automated checkers. |
There's a separate PR to do just that – #509 |
Um, I wouldn't say "okey with non-hierarchical", the key is that it is a logical representation of sections & sub-sections. It is possible to have a section of the page above the main content, such as the header & navigation, in which case you can have a (possibly hidden) H2 above the main content. The second example on H42 shows that. On the original question I'd say it is ok (and fairly common) to have an H2 above the main page's H1. What is odd though (in this example), is to have the error message above and before the H1, separated from the form. As @hannalaakso said, if the keyboard focus is moved to the error message onload that helps puts the focus on the new content and what the issues are, and then you want to get straight to the form inputs that need editing. |
And on top of the aforementioned change to the page title, the error summary box is also receiving focus, which means that a lot of screen readers jump there first (after reading the page title).
With the one-thing-per-page pattern, the h1 would be part of the form, mostly likely the label or legend. As mentioned in the description, it would be even weirder if the error summary came between the label and the input. But the example shows a different case. |
|
Ok as numerous people keep asking me my views on this, here goes. I personally did not have a problem with the previous pattern, I actually quite liked it, , as it worked great for everyone and was consistent across services. You can have more than one H1 per page if they are used in different sections, which an error summary is. Placing a heading at a lower level prior to an H1 does suggest that it isn't as important as the content in the main content area, but I think an error summary is crucial, so should get equal status to an H1. I would feel different if the sections prior to the main content was for navigation use, but thankfully we now have landmarks for this purpose. There are those like DAC as mentioned earlier in this thread that think it is good practice to have only one H1 per page, but that same person at DAC also believes that all required form fields are marked with a *.. As a screen reader user myself I depend on headings, and I find it quite annoying when the first heading in the page structure is skipping a heading level, which this proposed new pattern does. It doesn't create any barriers (neither did the previous pattern), but it does confuse me, as I think I've skipped a level. I also agree that moving the H2 below the main H1 is not the solution either. We should have left it alone in my view and none of the people in favour of the change on this thread have convinced me otherwise. Placing an H2 prior to an H1 seems like a hang-over from the CMS HTML 4 days where users chose a heading level based on the visual appearance and were unable to use landmarks. I am sure most screen reader users won't notice or care, but that doesn't make it right. Earlier in the thread it was stated that W3C are not bothered by heading levels and linked to a page that showed H2s appearing prior to the H1, but that page also states: "note that the example code below is not intended to prescribe what level of heading should be used for a particular section of the web page. In the example, the layout could be presented with the first heading in each column at the same logical level (such as an h1), or as found in the example, where the logical level reflects its importance in relation to the main content." So indeed, you could have an H1 for each of the sections. In my view, we've changed something that did not need changing as having the error summary as an H1 provided equal importance to the start of the main content area, the new pattern makes the error summary less important. Next we should focus on researching if error summaries are actually needed on one thing per page and try to alert users of an error as they happen and not after they've attempted to progress to the next page. |
I think it is more to do with the typical design of pages having significant content above the main content area, such as header, navigation etc. On gov.uk the header is very minimal so it isn't an issue, but in general most sites benefit from having headed sections above the main content. I agree it isn't a huge issue either way, but as I haven't seen a real example (going from a comment above) I won't comment further. |
|
Agree with Alastair - it's really common to have content above the main
page heading. Arguably that's why we have 'main' or skip links. Things like
error messages, notifications and such are often best placed right at the
top. I don't personally see the issue then with it being an appropriate
heading level for the type of content.
…On 24 July 2017 at 21:05, Alastair Campbell ***@***.***> wrote:
Placing an H2 prior to an H1 seems like a hang-over from the CMS HTML 4
days where users chose a heading level based on the visual appearance and
were unable to use landmarks.
I think it is more to do with the typical design of pages having
significant content above the main content area, such as header, navigation
etc.
On gov.uk the header is very minimal so it isn't an issue, but in general
most sites benefit from having headed sections above the main content.
I agree it isn't a huge issue either way, but as I haven't seen a real
example (going from a comment above) I won't comment further.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#510 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACGiQPg0oOEzkT7sJClm4fhBpt9aT3XFks5sRPkKgaJpZM4OJ7QV>
.
--
---
Ed Horsford
Designer
Government Digital Service
|
What problem does the pull request solve?
When there is an error in a form after submit, we show an error summary box above the h1. And the heading of that box is also an h1, making that two h1s per page.
The question why that is comes up again and again. For example, the accessibility audits by DAC (which a lot of departments are using) always raise that as an issue. And it was discussed a lot when it was first introduced in #71 (and previous PRs) and on various mailinglists.
As no visuals are affected, the main thing to look at is how screen reader users react to different heading levels.
I've been looking into how to "solve" this and if this really is an issue and tried various combinations:
I strongly believe that all of those variations are nearly equally fine. There are arguments for and against all of them. But none of them are ultimately really more accessible or more semantic or more right than the others.
The main problem why there is so much uncertainty around the subject and why even accessibility experts disagree on it is because HTML was not written for websites, it's written for web documents. It simply hasn't got the right semantic elements to build a meaningful website structure. Parts of that would have been solved with the document outline but that wasn't meant to be.
One thing we can hopefully all agree on, none of the solutions above is creating any barriers. As such, I wanted to go for the solution which will cause the least friction and follows the most accepted "best practice", so that we don't need to spend more time with answering support requests about this.
So, I propose to use an h2 instead of an h1 for the error summary heading.
It strengthens the "only one h1 per page" pattern and keeps things consistent. Although, I'm also aware that not everybody will be happy with that.
What about having the summary after the main heading?
The problem with that is that it will break the question and answer apart when using the "one thing per page" pattern.
What would solve that as well is to simply not have an error summary box on a page that follows that pattern as there will usually only be a maximum of one error, so you could jump straight to the error. In that case all other forms not following that pattern could have the summary box below the main heading.
But when they implemented the current solution they tried to do just that and it turned out to be much more complicated than expected. If someone has the resources to properly build the rules around that and user-test it, I think it might be the best solution. Until then we need to decide on the best quick solution.
How has this been tested?
This version was user-tested with a couple of screen reader users, and the change of heading hierarchy didn't cause any problems. No-one noticed anything off or was distracted by anything unexpected.
And I've also run it through a couple of accessibility checkers. FAE and aXe didn't return any issues. HTML_CodeSniffer (on which pa11y is based) came back with a warning (not an error):
What type of change is it?
Has the documentation been updated?
The documentation was already not specific about the heading level, so didn't need updating.