Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Focus not logical when error committed using the error summary component #1398

Closed
NickColley opened this issue May 31, 2019 · 2 comments
Closed

Focus not logical when error committed using the error summary component #1398

NickColley opened this issue May 31, 2019 · 2 comments
Assignees
@hannalaakso
Labels
accessibility audit may 2019 Issues from May 2019 external accessibility audit, before version 3.0.0 ⚠️ high priority Used by the team when triaging 🕔 hours A well understood issue which we expect to take less than a day to resolve.

Comments

@NickColley
Copy link
Contributor

NickColley commented May 31, 2019 •
edited
Loading

This issue is from a May 2019 external accessibility audit report.

WCAG Reference: 2.4.3 Focus Order (Level A)
Issue ID: DAC_Issue14
URL: http://govuk-frontend-v3.herokuapp.com/full-page-examples/passport-details#expiry-month
Page: Passport details

Summary

When an error had occurred, focus was taken to the second date field which was disorientating for some users

Screen Shot

When the form fields were left empty and the form submitted, the users focus was jumped to the second date entry field. This was confusing to users as it was not clear why this field had received focus.

Current Code Ref(s)

<input class="govuk-input govuk-date-input__input govuk-input--width-2 govuk-input--error" id="expiry-month" name="expiry-month" type="number" pattern="[0-9]*">

Screen reader comments

“When I committed an error by leaving all of the form fields empty, I found that my focus was taken to the ‘Month’ field and the heading ‘There is a problem’ as expected. I was not sure whether I was supposed to enter the ‘Day’ field as this had been missed.”

Keyboard only comments:

“I could not understand why my focus was taken to the second date field when I hadn’t entered any data into any of the form fields. I had to re-navigate the page to get to the list of error links at the top of the form which was time consuming for me.”

Solution

Ensure that when the user commits an error on the page, focus is sent to the error summary heading. Once the error link is selected, focus must be placed on the first field in a group.
@NickColley NickColley added accessibility audit may 2019 Issues from May 2019 external accessibility audit, before version 3.0.0 🕔 hours A well understood issue which we expect to take less than a day to resolve. ⚠️ high priority Used by the team when triaging labels May 31, 2019
@NickColley
Copy link
Contributor Author

I have assigned priority high since after an initial discussion with the team.

Since when the error summary links are clicked they leave the anchor id for the input in the URL, if you submit the form again you will skip to the previously errored input.

In GOV.UK Elements this behaviour was prevented but we did not introduce this in GOV.UK Frontend as we were not sure why this was done.

We could either

  1. Write guidance to ensure users do not use <form> elements without an explicit 'action'
  2. Re-introduce the behaviour in GOV.UK Elements which stops the anchor ID from being added to the URL when interacting with the error summary component.

I would recommend doing 2. since 1. feels easy to miss for our users.

@NickColley NickColley changed the title Focus not logical when error committed (A) Focus not logical when error committed using the error summary component May 31, 2019
@hannalaakso hannalaakso self-assigned this Jun 4, 2019
hannalaakso added a commit that referenced this issue Jun 6, 2019
@hannalaakso
Don't append hash when error summary link clicked
f038249 
When error summary links are clicked, this adds a hash to the URL.
As reported in #1398,
if the form is submitted again with further errors, the hash will stop
the error summary being focused as should happen and instead the element
with the hash ID is scrolled to which is confusing for the user.

This behaviour was prevented in GOV.UK Elements but we were not sure at
the time why this was necessary so it wasn't reintroduced in GOV.UK Frontend.
As we need to use preventDefault() to stop the page scrolling to the form element
itself and to show the error message above to make it clear what happened,
we programmatically reintroduced the hash to the URL to replicate browser
behaviour.

Following the bug report #1398, the code that adds the hash is redundant
and can be removed.

Co-authored by: Oliver Byford <oliver.byford@digital.cabinet-office.gov.uk>
@hannalaakso hannalaakso mentioned this issue Jun 6, 2019
Merged
hannalaakso added a commit that referenced this issue Jun 6, 2019
@hannalaakso @36degrees
Don't append hash when error summary link clicked
f13fe1f 
When error summary links are clicked, this adds a hash to the URL.
As reported in #1398,
if the form is submitted again with further errors, the hash will stop
the error summary being focused as should happen and instead the element
with the hash ID is scrolled to which is confusing for the user.

This behaviour was prevented in GOV.UK Elements but we were not sure at
the time why this was necessary so it wasn't reintroduced in GOV.UK Frontend.
As we need to use preventDefault() to stop the page scrolling to the form element
itself and to show the error message above to make it clear what happened,
we programmatically reintroduced the hash to the URL to replicate browser
behaviour.

Following the bug report #1398, the code that adds the hash is redundant
and can be removed.

Co-authored-by: Oliver Byford <oliver.byford@digital.cabinet-office.gov.uk>
aliuk2012 pushed a commit that referenced this issue Jun 14, 2019
@hannalaakso @36degrees @aliuk2012
Don't append hash when error summary link clicked
fd65f89 
When error summary links are clicked, this adds a hash to the URL.
As reported in #1398,
if the form is submitted again with further errors, the hash will stop
the error summary being focused as should happen and instead the element
with the hash ID is scrolled to which is confusing for the user.

This behaviour was prevented in GOV.UK Elements but we were not sure at
the time why this was necessary so it wasn't reintroduced in GOV.UK Frontend.
As we need to use preventDefault() to stop the page scrolling to the form element
itself and to show the error message above to make it clear what happened,
we programmatically reintroduced the hash to the URL to replicate browser
behaviour.

Following the bug report #1398, the code that adds the hash is redundant
and can be removed.

Co-authored-by: Oliver Byford <oliver.byford@digital.cabinet-office.gov.uk>
aliuk2012 pushed a commit that referenced this issue Jun 14, 2019
@hannalaakso @36degrees @aliuk2012
Don't append hash when error summary link clicked
2b46784 
When error summary links are clicked, this adds a hash to the URL.
As reported in #1398,
if the form is submitted again with further errors, the hash will stop
the error summary being focused as should happen and instead the element
with the hash ID is scrolled to which is confusing for the user.

This behaviour was prevented in GOV.UK Elements but we were not sure at
the time why this was necessary so it wasn't reintroduced in GOV.UK Frontend.
As we need to use preventDefault() to stop the page scrolling to the form element
itself and to show the error message above to make it clear what happened,
we programmatically reintroduced the hash to the URL to replicate browser
behaviour.

Following the bug report #1398, the code that adds the hash is redundant
and can be removed.

Co-authored-by: Oliver Byford <oliver.byford@digital.cabinet-office.gov.uk>
@NickColley
Copy link
Contributor Author

Confirmed as fixed in a re-test by DAC on 7th October 2019

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

@hannalaakso hannalaakso

Labels
accessibility audit may 2019 Issues from May 2019 external accessibility audit, before version 3.0.0 ⚠️ high priority Used by the team when triaging 🕔 hours A well understood issue which we expect to take less than a day to resolve.
Projects
GOV.UK Design System cycle board
Archived in project
Milestone
No milestone
Development

No branches or pull requests
3 participants
@36degrees @NickColley @hannalaakso