New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reflect form validation error in title #509

Merged
merged 3 commits into from Jul 31, 2017

Conversation

Projects
None yet
6 participants
@selfthinker
Member

selfthinker commented Jun 29, 2017

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.

@gemmaleigh gemmaleigh temporarily deployed to govuk-elements-review-pr-509 Jun 29, 2017 Inactive

@robinwhittleton

This comment has been minimized.

Contributor

robinwhittleton commented Jun 30, 2017

That’s a really interesting proposal 👍

@stevenaproctor

This comment has been minimized.

stevenaproctor commented Jun 30, 2017

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

This comment has been minimized.

stevenaproctor commented Jun 30, 2017

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

This comment has been minimized.

adamsilver commented Jun 30, 2017

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

This comment has been minimized.

stevenaproctor commented Jun 30, 2017

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

This comment has been minimized.

adamsilver commented Jun 30, 2017

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

@stevenaproctor

This comment has been minimized.

stevenaproctor commented Jun 30, 2017

@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

This comment has been minimized.

adamsilver commented Jun 30, 2017

@selfthinker

This comment has been minimized.

Member

selfthinker commented Jul 3, 2017

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 selfthinker force-pushed the reflect-error-in-title branch from cb75315 to 4bfd72c Jul 3, 2017

@selfthinker

This comment has been minimized.

Member

selfthinker commented Jul 3, 2017

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

This comment has been minimized.

stevenaproctor commented Jul 3, 2017

@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 selfthinker force-pushed the reflect-error-in-title branch from 4bfd72c to 4f7db35 Jul 3, 2017

@selfthinker

This comment has been minimized.

Member

selfthinker commented Jul 3, 2017

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

This comment has been minimized.

Contributor

edwardhorsford commented Jul 5, 2017

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

This comment has been minimized.

Member

selfthinker commented Jul 13, 2017

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 selfthinker force-pushed the reflect-error-in-title branch from 4f7db35 to 55082fe Jul 28, 2017

@selfthinker

This comment has been minimized.

Member

selfthinker commented Jul 28, 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.

selfthinker added some commits Jun 29, 2017

Rearrange validation implementation advice
Some points of the validation implementation advice were duplicated.
This is rearranging and rephrasing them to merge them together.
Reflect form validation error in title
This adds guidance to prefix the `title` with "Error: "
to alert screen reader users as soon as possible
that there has been an error after submitting a form.
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.

@selfthinker selfthinker force-pushed the reflect-error-in-title branch from 55082fe to 009d405 Jul 28, 2017

@gemmaleigh gemmaleigh merged commit be2d690 into master Jul 31, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@gemmaleigh gemmaleigh deleted the reflect-error-in-title branch Jul 31, 2017

@36degrees 36degrees referenced this pull request Oct 3, 2017

Merged

Release v3.1.2 #563

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment