Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Reflect form validation error in title #509
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.
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
This was very successfully user-tested with screen reader users, with users actively pointing out how useful it is.
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:
Those are the ones we care most about, but for completeness' sake, I have also tested:
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?
Has the documentation been updated?
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.
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 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:
We have just started this work so, hopefully, expect something in the next few weeks.
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" ***@***.***> 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 <#509 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACRKwhcV86fvymtfZEHNkpR88-6t0SVks5sJUEOgaJpZM4OJyR6> .
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 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.
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.
Are you happy with that? If not, what would you change?
referenced this pull request
Jul 21, 2017
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.