iron-collapse is focusable (by clicking or tabbing into it), which produces a focus outline in browsers

[punzki]

(Copied from Polymer/polymer#1760)

Illustrated by demo: https://elements.polymer-project.org/elements/iron-collapse?view=demo:demo/index.html

Clicking on the content inside core-collapse, or tabbing into it, produces an ugly "focused" outline (on Chrome, a glowing blue outline). In my opinion, this should not be the desired behavior. The element controlling the iron-collapse (e.g., a button) is the one that should be focusable, and the developer is the one that should be responsible for making sure that it is. Making the iron-collapse focusable doesn't achieve anything useful.

The hostAttributes of iron-collapse has tabindex: 0, which is causing this behavior. There's no way to remove the behavior. Even setting tabindex="-1" in the iron-collapse element makes it focusable on click (strange, because it isn't tabbable).

core-collapse in v0.5 does not have this behavior; I'd say this a regression.

P.S. I'd love for this to be my first pull request/contribution to open source on GitHub, if you devs agree with me and would let me. 😃

[alice]

Agreed that it doesn't make sense for iron-collapse itself to be focusable. I misunderstood the original demo when I suggested that, my apologies.

That said, it would be nice if the onus weren't on the developer to add the correct ARIA states and properties to the controlling button (see http://thepaciellogroup.github.io/disclosure-button/example2.html for an example of what states and properties are needed) - currently they're auto-added to the iron-collapse which is not quite correct. Perhaps something like iron-collapse-button is needed.

[notwaldorf]

Hmm, unfortunately anything can be a "controlling" button (i.e a paper-button or a paper-item, or even native buttons like in the demo.), and the only thing these things have in common is the fact that they have an ARIA state. Adding a behaviour just for that seems a bit like overkill, and would only fix custom elements -- native elements will have to be made accessible by the user anyway.

/cc @cdata @morethanreal for input

[alice]

I see - and you normally wire up the iron-collapse by just toggling its opened bit or using toggle(), so it's not linked in any meaningful way.

Semantically, the thing that controls the iron-collapse needs to know about its state so that it can set its aria-expanded value (i.e. the controller is the thing that's considered expanded or collapsed, not the collapsible area - this fits with the general advice to keep semantics with the elements you actually interact with).

Would it be too heavyweight to create some kind of container for both the controller which handles both wiring up the mouse/touch/keyboard behaviour of the controller and managing its semantic attributes? Or is there some other way we can reach out and modify the controller, e.g. having the iron-collapse take a controller attribute which uses an IDREF (bleh)?

[alice]

At the very minimum, though, if we're going to require developers to handle their own ARIA attributes, then the demo code inside iron-collapse.html as well as the associated demo should both demonstrate how to create an accessible disclosure widget with iron-collapse.

[davidmaxwaterman]

Was this ever resolved? I still see the iron-collapse getting the ugly blue border, and I struggle to see how to stop it (short of forking iron-collapse and removing the this.focus() call on line 277 (on 1.X branch)).
There's a mention of altering one of the demos to show how to do this, isn't there?
Perhaps there is some obvious way to remove this behaviour - if so, could someone add it to this issue so people who come here can find it? Thanks :)

Edit:
I see that the following does the trick. Is this the way it is supposed to be done? :

  iron-collapse:focus {
    outline: none;
  }

[web-padawan]

@davidmaxwaterman consider using another way to highlight element after removing outline for a11y. Elements like paper-button do this using PaperInkyFocusBehavior.

[davidmaxwaterman]

Yeah, I thought about that, but tbh I don't see the point - the whole point of my UI is that all other collapse items are hidden and this one is shown, so it is perfectly obvious what is happening - there's only one anyway. Also, I kind of agree with the original poster that it is the button that triggered the opening of the collapsible element that should be focused, rather than the collapsible element itself.