[Webkit-unassigned] [Bug 171006] New: AX: Focus always on button after posting form when using VoiceOver

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Apr 19 13:23:37 PDT 2017


            Bug ID: 171006
           Summary: AX: Focus always on button after posting form when
                    using VoiceOver
           Product: WebKit
           Version: Safari 10
          Hardware: Macintosh
                OS: OS X 10.11
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Accessibility
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: anika.henke at digital.cabinet-office.gov.uk
                CC: webkit-bug-importer at group.apple.com

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")
6. 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.)

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.

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...

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170419/8714d36d/attachment.html>

More information about the webkit-unassigned mailing list