You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Submit the form (without filling in the form field) by using VO + space (the focus is correctly on the "error message")
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...
The text was updated successfully, but these errors were encountered:
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.
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
(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...
The text was updated successfully, but these errors were encountered: