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.

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

Add guidance on linking from the error summary #634

Merged
merged 7 commits into from Nov 16, 2018

Conversation

@36degrees
Copy link
Contributor

commented Nov 14, 2018

This introduces guidance to help service teams link from the error summary to the corresponding questions in an accessible way.

👉You can preview this change here: https://deploy-preview-634--govuk-design-system-preview.netlify.com/components/error-summary/

Our approach mirrors the recommended approach from WebAIM, linking to the input in all cases.

This does mean that the input would natively be focussed at the top of the viewport, which means the associated label or legend would not be visible to the user. There is a corresponding change to Frontend to manually manage the focus and scroll state, allowing us to target and focus the input whilst scrolling to the label or legend.

To understand how to do this in an accessible way, we carried out research using a simplified test case and the assistive technologies we aim to support:

Voiceover + Safari (macOS El Capitan)

The behaviour differs depending on whether you use Enter or Ctrl-Opt-Space to navigate.

When navigating using Enter:

  • linking to the label or legend generally resulted in the focus moving but nothing being announced.
  • linking to the input generally worked well, but the error message (associated using aria-describedby) was not announced for radios or checkboxes.

When navigating using Ctrl-Opt-Space:

  • linking to a label worked but it was not clear how to interact with the related form contrl (the label would be read followed by "You are currently on a text element, inside of web content. To exit this web area, press Ctrl-Option-Shift-Up Arrow.")
  • linking to the input worked OK, but the associated legend and error message were not read out for inputs within a fieldset

Overall, linking to the input worked better.

Voiceover + Safari (iOS 11)

There doesn't seem to be any way to get Voiceover on iOS to do anything useful, regardless of where you link to. For everything except selects and file inputs (!?) linking to the input results in the focus and VO cursor moving, but nothing being announced. Linking to the label or legend caused Voiceover to repeat itself, and neither the focus nor the VO cursor moved at all.

There is no good option. 🤷‍♂️

We've filed a number of bugs against WebKit that relate to the way VoiceOver behaves when linking to different types of input.

TalkBack + Google Chrome (Android)

Linking to the input worked OK, but the associated legend and error message were not read out for inputs within a fieldset.

Linking to labels resulted in the page scrolling but nothing being announced. Linking to legends resulted in the legend and error message being read, but with no clear way to navigate to the corresponding control.

Overall, linking to the input worked better.

NVDA + Firefox

Linking to the input only described the input type, without reading any of the associated context (label, legend, error message). We've filed a bug against NVDA to try and get this fixed.

Linking to the label resulted in the label being read out, preceded by 'clickable'.

Overall, linking to the label worked better. However, the manual focus state management introduced in alphagov/govuk-frontend#1056 means that linking to the input now works really well, announcing all expected context.

JAWS2018 + IE11

Linking to the label resulted in the focus shifting down but then immediately returning to the top of the page and enters reading mode.

Linking to the input generally worked well, but the error message was not read in some cases (text areas, and error messages associated with fieldsets)

Overall, linking to the input worked better.

Dragon NaturallySpeaking

Clicking links using Naturally Speaking's commands worked as expected in all cases.


https://trello.com/c/OHeUK8Df/1452-add-guidance-to-help-users-understand-how-to-link-from-the-error-summary-to-different-types-of-input

Add guidance on linking from the error summary
This introduces guidance to help service teams link from the error summary to the corresponding questions in an accessible way.

Our approach mirrors the recommended approach from WebAIM [1], linking to the input in all cases.

This does mean that the input would natively be focussed at the top of the viewport, which means the associated label or legend would not be visible to the user. There is a corresponding change to Frontend [2] to manually manage the focus and scroll state, allowing us to target and focus the input whilst scrolling to the label or legend.

To understand how to do this in an accessible way, we carried out research using a simplified test case [3] and the assistive technologies we aim to support:

## Voiceover + Safari (macOS El Capitan)

The behaviour differs depending on whether you use Enter or Ctrl-Opt-Space to navigate.

When navigating using Enter:

- linking to the label or legend generally resulted in the focus moving but nothing being announced.
- linking to the input generally worked well, but the error message (associated using aria-describedby) was not announced for radios or checkboxes.

When navigating using Ctrl-Opt-Space:
- linking to a label worked but it was not clear how to interact with the related form contrl (the label would be read followed by "You are currently on a text element, inside of web content. To exit this web area, press Ctrl-Option-Shift-Up Arrow.")
- linking to the input worked OK, but the associated legend and error message were not read out for inputs within a fieldset

Overall, linking to the input worked better.

## Voiceover + Safari (iOS 11)

There doesn't seem to be any way to get Voiceover on iOS to do anything useful, regardless of where you link to. For everything except selects and file inputs (!?) linking to the input results in the focus and VO cursor moving, but nothing being announced. Linking to the label or legend caused Voiceover to repeat itself, and neither the focus nor the VO cursor moved at all.

There is no good option. ¯\_(ツ)_/¯

## TalkBack + Google Chrome (Android)

Linking to the input worked OK, but the associated legend and error message were not read out for inputs within a fieldset.

Linking to labels resulted in the page scrolling but nothing being announced. Linking to legends resulted in the legend and error message being read, but with no clear way to navigate to the corresponding control.

Overall, linking to the input worked better.

## NVDA + Firefox

Linking to the input only described the input type, without reading any of the associated context (label, legend, error message).

Linking to the label resulted in the label being read out, preceded by 'clickable'.

Overall, linking to the label worked better. However, the manual focus state management introduced in alphagov/govuk-frontend#1056 means that linking to the input now works really well, announcing all expected context.

## JAWS2018 + IE11

Linking to the label resulted in the focus shifting down but then immediately returning to the top of the page and enters reading mode.

Linking to the input generally worked well, but the error message was not read in some cases (text areas, and error messages associated with fieldsets)

Overall, linking to the input worked better.

## Dragon NaturallySpeaking

Clicking links using Naturally Speaking's commands worked as expected in all cases.

[1]: https://webaim.org/techniques/formvalidation/
[2]: alphagov/govuk-frontend#1056
[3]: https://36degrees.github.io/linking-to-form-inputs/
@36degrees

This comment has been minimized.

Copy link
Contributor Author

commented Nov 14, 2018

@amyhupe would you mind reviewing the guidance?

@dashouse would you mind reviewing the design of the examples?

@36degrees 36degrees requested review from amyhupe and dashouse and removed request for amyhupe Nov 14, 2018

@govuk-design-system-ci

This comment has been minimized.

Copy link
Collaborator

commented Nov 14, 2018

You can preview this change here:

Built with commit ded94d3

https://deploy-preview-634--govuk-design-system-preview.netlify.com

@36degrees 36degrees requested a review from amyhupe Nov 14, 2018

fieldset: {
legend: {
isPageHeading: true,
text: 'Label for date input',

This comment has been minimized.

Copy link
@dashouse

dashouse Nov 14, 2018

Contributor

I assume this should be the question?

This comment has been minimized.

Copy link
@36degrees

36degrees Nov 14, 2018

Author Contributor

😬

@amyhupe
Copy link
Contributor

left a comment

I've made a few suggestions - let me know if any are unclear.

src/components/error-summary/index.md.njk Outdated Show resolved Hide resolved
src/components/error-summary/index.md.njk Outdated Show resolved Hide resolved
src/components/error-summary/index.md.njk Outdated Show resolved Hide resolved
src/components/error-summary/index.md.njk Outdated Show resolved Hide resolved

You must link the errors in the error summary to the question they relate to.

For questions that use a single field, for example the character count, file upload, select, textarea or text input components, link to the field.

This comment has been minimized.

Copy link
@amyhupe

amyhupe Nov 14, 2018

Contributor
Suggested change
For questions that use a single field, for example the character count, file upload, select, textarea or text input components, link to the field.
Where a user has to answer using a single field, for example, a character count, file upload, select, textarea or text input components, link to the field.

This comment has been minimized.

Copy link
@36degrees

36degrees Nov 14, 2018

Author Contributor

I don't think that's quite right, because it suggests that fields == components which is not right. Should we also use 'form controls' here?

Suggested change
For questions that use a single field, for example the character count, file upload, select, textarea or text input components, link to the field.
Where a user answers using a single form control, for example, if you are using a character count, file upload, select, textarea or text input component, link to the field.
src/components/error-summary/index.md.njk Outdated Show resolved Hide resolved

{{ example({group: "components", item: "error-summary", example: "linking-multiple-fields", html: true, nunjucks: true, open: false, size: "s"}) }}

For questions that use multiple inputs, such as the checkboxes or radios components, link to the first checkbox or radio.

This comment has been minimized.

Copy link
@amyhupe

amyhupe Nov 14, 2018

Contributor

It doesn't seem quite right to me to call these inputs and the above examples 'fields' as, for example, we say 'text input'. Suggest changing to:

Suggested change
For questions that use multiple inputs, such as the checkboxes or radios components, link to the first checkbox or radio.
For questions that use multiple form controls, such as the checkboxes or radios components, link to the first checkbox or radio.

This comment has been minimized.

Copy link
@36degrees

36degrees Nov 14, 2018

Author Contributor

I like the use of 'form controls' – should we change 'fields' to 'form controls' throughout?

"errorList": [
{
"text": "Enter your date of birth and include a day, month and year",
"href": "#dob-year"

This comment has been minimized.

Copy link
@nickcolley

nickcolley Nov 14, 2018

Contributor

In the guidance it says you need to link to the first field, but we link to the last field, is this intentional?

This comment has been minimized.

Copy link
@nickcolley

nickcolley Nov 14, 2018

Contributor

Oh wait, I guess the idea is that the example is of something where you do know the wrong feild....

This comment has been minimized.

Copy link
@36degrees

36degrees Nov 14, 2018

Author Contributor

Yep. I've updated the example to make this clearer (only adding the govuk-input--error class to the year input)

36degrees and others added some commits Nov 14, 2018

Replace 'questions' with 'answers'
It'll be the answer, rather than the question, that contains an error.

Co-Authored-By: 36degrees <oliver.byford@digital.cabinet-office.gov.uk>
Remove repetition of 'for example', and the negative contraction.
Co-Authored-By: 36degrees <oliver.byford@digital.cabinet-office.gov.uk>

Suggestions have been applied

@36degrees 36degrees referenced this pull request Nov 16, 2018
22 of 22 tasks complete
@kr8n3r

kr8n3r approved these changes Nov 16, 2018

Copy link

left a comment

quality : 💯

@36degrees 36degrees merged commit af65c83 into master Nov 16, 2018

3 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
deploy/netlify Deploy preview ready!
Details

@36degrees 36degrees deleted the add-guidance-error-summary branch Nov 16, 2018

@colinrotherham

This comment has been minimized.

Copy link

commented Nov 16, 2018

@36degrees Thanks for linking me to this, it's loads better!

Maybe add a further pull request with example errors inside a conditional reveal for completeness? Probably go all the way and add radio buttons, select, upload and textarea examples as well.

Speaking to other developers, the biggest issue is a lot don't understand the magic relationship between labels, legends, id and aria-describedby attributes (plus the aria-labelledby on the alert).

Is the design system the wrong place to talk about this?

The pull request talks about "fields" and "answers" so maybe it's untechnical on purpose.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.