Open
Bug 1392676
Opened 7 years ago
Updated 2 years ago
a11y test of address form autofill
Categories
(Firefox :: Disability Access, defect, P3)
Firefox
Disability Access
Tracking
()
NEW
People
(Reporter: MattN, Unassigned)
References
Details
(Whiteboard: [form autofill])
Thanks for reviewing the autofill UX spec in bug 1347084. Now that address autofill has stabilized it would be great if an a11y-review was done on the implementation of the feature. The feature is planning to ship with Firefox 56 in en-US for users geographically in the US but for now it's best to test on Nightly to avoid the geolocation checks.
You can use pages at https://luke-chang.github.io/autofill-demo/ to test the autofill feature. The first time you submit an address form with 3+ values it should save an autofill profile.
Things to review:
A) The autocomplete popup and the autofill function
* Including the "Also autofills"… text and opening of preferences
B) Autofill preferences, manage dialog, and edit/new dialog under Privacy and Security preferences
C) The first-time use doorhanger for when an address form is submitted. You can reset extensions.formautofill.firstTimeUse to false in about:config to see it again.
Let me know if you need any more info or clarification.
Thanks
Flags: needinfo?(yzenevich)
Flags: a11y-review?
Comment 1•7 years ago
|
||
I will try out keyboard nav with contrast and applicable semantics; Marco would you have some cycles to see if it works well with any of the screen readers?
Flags: needinfo?(yzenevich) → needinfo?(mzehe)
Comment 2•7 years ago
|
||
(In reply to Matthew N. [:MattN] (huge backlog; PM if requests are blocking you) from comment #0)
> Things to review:
> A) The autocomplete popup and the autofill function
This works in principle. I get the message that an input supports auto completion as has always been the case, and when I press DownArrow, if I already have an address input, I also get the entry for the address spoken and selected in a list box, in my case item 1 of 2.
> * Including the "Also autofills"… text and opening of preferences
This is where there is still a problem, as Yura will also discover via keyboard. You cannot get to this via the keyboard. Pressing DownArrow again from that first item will dismiss the popup. I would expect DownArrow to move to the next item.
Next problem: The widget to open Preferences is not a button. And it cannot be reached via the keyboard, only via mouse click.
My suggestion would be to allow selection to move to that item, and Enter executing that Preferences button when focused on that item.
> B) Autofill preferences, manage dialog, and edit/new dialog under Privacy
> and Security preferences
Those work fine from a screen reader standpoint.
> C) The first-time use doorhanger for when an address form is submitted. You
> can reset extensions.formautofill.firstTimeUse to false in about:config to
> see it again.
This one also works like other doorhangers.
Flags: needinfo?(mzehe)
Comment 3•7 years ago
|
||
Couple of initial comments:
* As Marco pointed out, with mouse "Also autofills ..." acts as a link to prefs. This is not the case with the keyboard. I'm not sure we need this redundancy but if we want to preserve parity between mouse and keyboard, that slot should also be focusable and actionable.
* Selected item background color matches the background color of the preferences link (last item) it makes it pretty confusing to figure out where keyboard focus is. Ideally those 2 need to be different or focus should have additional styling (like border)
* I got myself into a situation where I hit some JS errors with autofill and it stopped working for me. Specifically:
TypeError: address is undefined in FormAutofillParent.jsm:301:1
also "Sending message that cannot be cloned. Are you trying to send an XPCOM object?" that would pop up every time I try to press arrow down to open autofill.
Comment 4•7 years ago
|
||
Regarding the doorhanger. This is likely not an autofill issue but they are generally pretty inaccessible. They should have aria-live attribute set on them. Otherwise the screen reader user will have no idea something popped up. In terms of keyboard accessibility they are also no accessible. The best a keyboard user can do is to go into url bar, manage to focus on the autofill-address-notification-icon button to open it and press ESC to close it. There is not way to step into the doorhanger itself, to Change outfill options.
Comment 5•7 years ago
|
||
(In reply to Yura Zenevich [:yzen] from comment #4)
> Regarding the doorhanger. This is likely not an autofill issue but they are
> generally pretty inaccessible. They should have aria-live attribute set on
> them. Otherwise the screen reader user will have no idea something popped
> up.
Not entirely correct, the doorhangers have a role of "alert" and thus an implicit ARIA-live attribute. They are being spoken by screen readers, at least for me on Windows, and on Linux, too.
> In terms of keyboard accessibility they are also no accessible. The best
> a keyboard user can do is to go into url bar, manage to focus on the
> autofill-address-notification-icon button to open it and press ESC to close
> it. There is not way to step into the doorhanger itself, to Change outfill
> options.
Once you make it reappear from the URL bar, you can tab into them. So they are as fiddly as other doorhangers generally, but not more than others.
Comment 6•7 years ago
|
||
Also autofills section might be low contrast for text for some users, otherwise looks good.
Comment 7•7 years ago
|
||
(In reply to Marco Zehe (:MarcoZ) from comment #5)
> (In reply to Yura Zenevich [:yzen] from comment #4)
> > In terms of keyboard accessibility they are also no accessible. The best
> > a keyboard user can do is to go into url bar, manage to focus on the
> > autofill-address-notification-icon button to open it and press ESC to close
> > it. There is not way to step into the doorhanger itself, to Change outfill
> > options.
>
> Once you make it reappear from the URL bar, you can tab into them. So they
> are as fiddly as other doorhangers generally, but not more than others.
Hm, interesting, I was not able to on OSX
Comment 8•7 years ago
|
||
(In reply to Yura Zenevich [:yzen] from comment #7)
> (In reply to Marco Zehe (:MarcoZ) from comment #5)
> > (In reply to Yura Zenevich [:yzen] from comment #4)
> > > In terms of keyboard accessibility they are also no accessible. The best
> > > a keyboard user can do is to go into url bar, manage to focus on the
> > > autofill-address-notification-icon button to open it and press ESC to close
> > > it. There is not way to step into the doorhanger itself, to Change outfill
> > > options.
> >
> > Once you make it reappear from the URL bar, you can tab into them. So they
> > are as fiddly as other doorhangers generally, but not more than others.
>
> Hm, interesting, I was not able to on OSX
Is your System Preferences/Keyboard setting showing that tab key should only focus input fields, or all focusable elements? If the former, then that's because you're not able to tab into the doorhanger. If the latter, there's a separate bug with doorhangers on OS X that pertains to focus manager not honoring that setting in this case. On Windows, this definitely works.
Updated•7 years ago
|
Flags: needinfo?(yzenevich)
Updated•7 years ago
|
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•