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

Focus is always on button after posting form when using VoiceOver #31

Closed
selfthinker opened this issue Jun 1, 2019 · 2 comments
Closed

Comments

@selfthinker
Copy link

Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=171006
Date: 2017-04-19
Reported by: Anika Henke
Related to: alphagov/govuk_elements#511


Overview

When posting a form (presumably to the same page), the next page that loads always focusses on the submit button. That only happens in Safari (not Chrome or Firefox) when VoiceOver is active. It doesn't happen when VoiceOver is disabled.

Steps to reproduce

  1. Activate VoiceOver
  2. Open Safari
  3. Open http://jsbin.com/toxarul (reduced test case)
  4. Submit the form (without filling in the form field) by using VO + space (the focus is correctly on the "error message")
  5. Submit the form again (without filling in the form field) by using VO + space
    (We could skip step 6 if JSbin allowed a post instead of a get.)

Actual result

The focus is on the submit button. There is sometimes a short delay and the error message is focussed first before the focus quickly moves onto the submit button, most often too quickly to read anything out loud, sometimes it reads the first word before moving to the button.

Expected result

The focus should be on the "error message". Even without the JavaScript that adds focus to the error message, the focus should not be on anything else.
It works as expected when VoiceOver is switched off, or when VoiceOver is used with Chrome or Firefox, or when just the space or enter key is used to submit the form. But VO key + space is what VoiceOver tells you to use when focussing on a button.

Why is this a problem?

When there are errors in a form, you would usually want to inform people about it. That can be done in multiple ways. When done by focussing on the error alert box to be read out immediately to screen readers, that focus will be removed from the alert box to the button. That means VoiceOver users who cannot see the screen will have no way of knowing an error appeared.
Another example where you can see that in action is on http://govuk-elements.herokuapp.com/errors/example-form-validation-multiple-questions. Submit the form, an alert box will appear but will not be announced as the focus is on the button. That will happen after the first submit.

Assumptions from testing various scenarios

This seems to only happen when the URL after the submit is the same as before. Posting to the same URL will always show that bug. When a get is used, this seems to only be true as long as the parameters in the URL stay the same. That is probably why the example form in the steps to reproduce needs to be submitted twice. When accessing the page with the empty text input in the URL [http://output.jsbin.com/toxarul?text=], the bug appears after the first submit. When filling in the form field with something, e.g. "test", the bug does not appear, unless you fill it again with the very same word and submit again.

This bug is probably not present in Safari on iOS, only on OS X. I say "probably" because there is another bug on iOS which moves the focus to somewhere else, which makes that difficult to verify. But that's another story...

@36degrees
Copy link
Contributor

Update on 2022-02-10:

The fix for this issue was needed outside the WebKit project, therefore this is being resolved as 'Moved'.

This should now be fixed in shipping software.

@36degrees 36degrees moved this from Open to Closed (Fixed) in Reported Bugs Jul 11, 2022
@edwardhorsford
Copy link

Testing with VoiceOver on iOS today, I am seeing this issue - if no errors are generated, then the next page has the submit button focused. If errors are generated, then focus is correctly moved (via js?) to the errorSummary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Closed (Fixed)
Development

No branches or pull requests

3 participants