Reflect form validation error in title

selfthinker commented 7 years ago

What problem does the pull request solve?

When a form submit wasn't successful and there are errors in the form which need to be highlighted, it is very important that every user is alerted to that as soon and effectively as possible. Although our solution for that is pretty good, it can still be improved. Seeing users, even those with low vision, can see the big red box pretty clearly. Even in case they cannot read the text easily, they will know something is wrong. So, it's mostly the journey for blind screen reader users we should be concerned about.

Because we automatically focus on the error summary, some screen readers read that out pretty early, while others never read it. But what most screen readers read first is the title. That's what we can use to make them aware that there has been an error as soon as possible.

That's why this adds guidance to prefix the title with something (like "Error in:"). It also adds the required code to the two validation example forms.

This was very successfully user-tested with screen reader users, with users actively pointing out how useful it is. It is also mentioned in the W3C's Web Accessibility Tutorial as a good practice example of how to notify users of interaction successes or failures. Changing the main heading would also be an option.

As some of the guidance was duplicated and overlapping a bit, this also moves it into a partial for re-use and rearranges some of its content.

One open question I still have is about the copy: Is "Error in: " a good example? I could also think of "Error - ". Who should I talk to to get feedback on that? What is our style?

How has this been tested?

This was tested in a couple of screen readers (always using the default configuration). All of these tests only reflect how they behave in case of a page with errors after a form post:

JAWS 17 in IE 11 reads the title first, except when following an anchor
NVDA in Firefox always reads the title first
none of the VoiceOver versions read the title at all
ZoomText never reads the title

Those are the ones we care most about, but for completeness' sake, I have also tested:

Narrator in IE 11 always reads the title first (if scan mode is off)
TalkBack in Chrome reads the title first, except when following an anchor or if there is a role=alert
ChromeVox in Chrome also always reads the title first

When the title is not read, this change doesn't change anything. But when the title is read first, that's an improvement over being alerted about the error a couple of seconds later or never in case a user decides to quickly navigate somewhere else within the page.

What type of change is it?

New feature (non-breaking change which adds functionality)

Has the documentation been updated?

I have updated the documentation accordingly.
I have read the CONTRIBUTING document.

robinwhittleton commented 7 years ago

That’s a really interesting proposal 👍

stevenaproctor commented 7 years ago

When I use NVDA with Firefox, assuming the focus is set correctly, the h1 in the summary box is always read out first, not the page title. I tested it with the 2 examples in elements and it worked OK.

stevenaproctor commented 7 years ago

I am not sure the W3C guidance means dynamically changing the page title or heading of the page you are currently on. The examples seem to me to be different pages, but that is only my interpretation of them.

adamsilver commented 7 years ago

Universal Credit uses this approach. We prepend "Retry - " to the page title. We don't have client-side validation, so this is always through a ‘postback page refresh’. I don't have research to hand, but I believe the RNIB suggested we do this and screen readers users have found this useful.

stevenaproctor commented 7 years ago

If this helps people I am all for it. I would avoid "error" or "mistake" because they imply blame. "Retry" or "Try again" would be better.

It would be interesting to know what people put as the heaing in the summary box because there is no standard. I have seen "There is a problem" "There is a problem with the form", "This page has errors", and "There was a problem submitting the form". I am sure there are others.

Tax credits uses "There is a problem" and it tested well with people. I would not want to mention "submitting" and "form" because it's jargon.

adamsilver commented 7 years ago

@stevenaproctor is there any guidance from GDS or otherwise with regards to error messages?

stevenaproctor commented 7 years ago

@adamsilver There is just the guidance in elements https://govuk-elements.herokuapp.com/errors/ and Dropbox https://paper.dropbox.com/doc/fifEJpOYMGjRy0lHTmthb

At HMRC we are working on standardising errors for different types of form field for consistency. We will share whatever we come up. It would be good to have a single standard that includes:

location of the summary box (if you consider breadcrumbs, back links, h1s)
what the heading in the summary box should be
different use cases and error message content

We have just started this work so, hopefully, expect something in the next few weeks.

adamsilver commented 7 years ago

That's awesome. We are looking at the exact same things :) Will let you know what comes out of ours too.

On 30 Jun 2017 7:40 pm, "Steven Proctor" notifications@github.com wrote:

@adamsilver https://github.com/adamsilver There is just the guidance in elements https://govuk-elements.herokuapp.com/errors/ and Dropbox https://paper.dropbox.com/doc/fifEJpOYMGjRy0lHTmthb

At HMRC we are working on standardising errors for different types of form field for consistency. We will share whatever we come up. It would be good to have a single standard that includes:

location of the summary box (if you consider breadcrumbs, back links, h1s)

what the heading in the summary box should be

different use cases and error message content

We have just started this work so, hopefully, expect something in the next few weeks.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alphagov/govuk_elements/pull/509#issuecomment-312343742, or mute the thread https://github.com/notifications/unsubscribe-auth/AACRKwhcV86fvymtfZEHNkpR88-6t0SVks5sJUEOgaJpZM4OJyR6 .

selfthinker commented 7 years ago

Fair point about the language. I think it's probably best to change so it doesn't give any example but rather says to repeat the same words you use for the heading of the summary box. As people will (hopefully) have good and thoughtful copy for that (e.g. "There is a problem") and you'd have a direct correlation to what's already there, it would be good to use that.

I think having some guidance about the copy would be really helpful. Changing e.g. "Message to alert the user to a problem goes here" which is currently in Elements to something clear and re-usable would be very helpful. Sounds like a good side project for some tech writers, if anyone finds the time. Those things must have been user tested before, haven't they?

I don't think dynamically changing the page title would make much sense as I don't think it would be read again at any point? So, only doing this in the backend after the form has been submitted makes sense.

Interesting about your NVDA version reacting differently. I'll try a few other versions and OS or browser combinations. It's not really important for this PR but interesting to know.

selfthinker commented 7 years ago

I have just adjusted the copy to not give a specific example except repeating whatever the error summary heading is. And I changed the page title of the two example forms from "Error in: " to "There was a problem - ".

stevenaproctor commented 7 years ago

@selfthinker I would change that to "There is a problem" because the problem is in the present.

I agree 100% agree about improving the language that is in elements. Hopefully what we or DWP produce can be added to elements and the service manual.

I think we need to get rid of generic or placeholder content from elements and patterns wherever possible.

selfthinker commented 7 years ago

Changing to "There is a problem" makes sense. I've just changed it.

Yes, after HMRC and DWP researched their improvements, it would be great to have the results feed back to Elements to get rid of placeholder content. :)

edwardhorsford commented 7 years ago

I have a personal preference to Error: foo bar. I feel like a shorter and more concise message is more likely to get noticed. Error is pretty common language in this case.

@StephenGill what do you think?

selfthinker commented 7 years ago

I wouldn't concentrate on the exact content for the example pages, as their content is not great anyway and a bad example, especially for the page title. I would rather make improving that its own project. What's more important is to get the guidance right. Right now it's relatively broad:

prefix the <title> with something to indicate there has been an error on the page, for example by repeating the error summary heading

Are you happy with that? If not, what would you change?

selfthinker commented 7 years ago

We've had a meeting with @edwardhorsford and @stephengill today and decided to go back to prefix the title with the most simple form: "Error: ". We've discussed what @stevenaproctor raised that it would imply blame. The general thinking was to make it as succinct and clear as possible. But Ed and Stephen will be better at explaining their reasoning... (Can you post a summary here?)

I have just updated the code to reflect that decision, to rebase with master and to fix the conflict.

alphagov / govuk_elements