1466420 - Browser-style makes input elements un-focusable

Status: RESOLVED WONTFIX

(WebExtensions :: Frontend, defect, P3)

Description

[rugk]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180530201455

Steps to reproduce:

Follow https://developer.mozilla.org/en-US/Add-ons/WebExtensions/user_interface/Browser_styles and add the styles to your "input" elements.


Actual results:

As the styles do hide the actual input element and use the label (with a pseudo-element in before) for that, it makes them effectively unfocusable.

You cannot focus them anymore. This is bad for accessibility and more…

So when I manually add tabindex="0" to the labels then, you can focus them again, but you when you press space, it does not select/change the value.
If this is a different issue, feel free to open a new issue for that.


Expected results:

They should stay focusable.

Or, if the second problem with pressing space is resolved, the doc should mention that you need to add "tabindex" to all your labels of the inputs then.

Comment 1

[rugk]

You can test this in a live add-on in https://github.com/rugk/offline-qr-code/tree/browserStyle (notice the branch "browserStyle").

Comment 2

[Adrian Florinescu [:aflorinescu]]

Due to my lack of experience with this area, I don't understand what exactly is the problem here.
Rugk, could you please add a reduced test case(simplified example) which isolates the problem, preferably with a more detailed STR to follow?

Meanwhile I'm initially triaging this issue to extension compatibility.

Comment 3

[rugk]

I'll do that, soon.

Comment 4

[rugk]

Please involve someone, who knows something about accessibility. 

I'll attach my tests case. It includes detailed STR and a demonstration of the problem.

Comment 5

[rugk]

Attachment: forget-it-UnfocusableDueToBrowserStyle.zip

Comment 6

[rugk]

Okay, found the a11y-review flag, just added it, because it very obviously *IS* an accessibility issue for all WebExtensions, which use the browser-style.

Comment 7

[rugk]

Attachment: forget-it-UnfocusableDueToBrowserStyle-v2.zip

Just had to fix some text issues, I missed.

Comment 8

[rugk]

BTW, here is an article about how to style radio buttons (and similar) without scarifying accessibility: https://www.chenhuijing.com/blog/customise-radios-without-compromising-accessibility/

Also, can this be assigned to someone who knows what this is about? Or whatever team is responsible?

Comment 9

[Marco Zehe (:MarcoZ)]

(In reply to Adrian Florinescu [:adrian_sv] from comment #2)
> Due to my lack of experience with this area, I don't understand what exactly
> is the problem here.

The problem is that, as soon as you style an <input type="radio" or a <button> element with the class="browser-style", as mentioned in the MDN link from comment #0, the control itself is hidden from the browser and thus can no longer be tabbed to. The control becomes oblivious to keyboard users. The attached extension demonstrates this behavior. Also, for screen reader users, a once semantic element becomes non-semantic clickable text and thus inaccessible. I can no longer distinguish a button from a checkbox from a radio button etc.

There are two ways to fix this:

1. Apply the rules for styling elements in a way that doesn't hurt accessibility, as rugk suggested in comment #8, or

2. The less preferred method is to fiddle with the non-semantic stuff that gets inserted into the DOM in place of the actual input. This would require:
a) proper WAI-ARIA roles, states and properties for each control,
b) proper keyboard handling for each, including tracking the selection, checking and unchecking, or activating of items via the keyboard.

Option 1 sounds like a lot less work to me. :)

Please contact either Jamie or me from the accessibility team for help if you need it. You can also use the accessibility inspector in the dev tools to view results of what you apply to the elements.

Comment 10

[rugk]

BTW just my point from an add-on dev site about this: Option 2 is likely very hard to do, because it either requires the add-on developer to cooperate (i.e. put these aria roles etc. in the HTML text, already) or you also have to inject some custom JS, which adjusts the HTML code, in addition to the "browser-style" CSS. The latter could also have bad site effects depending on what the add-on dev already did/added in the add-on HTML.

Comment 11

[rugk]

Any news here? When will this be fixed?

Comment 12

[Caitlin Neiman [:caitmuenster]]

Moving this into the WebExtensions component for investigation.

Comment 13

[Rob Wu [:robwu]]

Closing bug because support for browser_style feature is going to be removed (at least in MV3), see bug 1827910.