[css-display][css-aam][selectors-4] How elements with `display:contents` get focused?

[SelenIT]

In #2355, we clarified that only display:none can affect the element's semantics and interactivity, so element with display: contents should preserve all its interactivity, including the ability to get the :focus (and :focus-visible) state. However, it's not clear how this state should work for this element.

Like the element with no boxes can be in :hover state (see #1141), making it possible to choose its descendants with selectors like .no-boxes-element:hover .something, I believe that the element that would receive focus without display: contents should receive it with display: contents as well. So its descendants should match the selectors like .no-boxes-element:focus .something, and its ancestors should match the :focus-within pseudo-class, making it possible to make the focus change visible despite the element itself is not displayed. And the fact that current browsers (at least, Firefox and Chrome) don't apply focus to the element with display:contents is the bug of these browsers. The element is still there in the DOM, it still can be activated, so there is no reason to skip the focus for it.

However, it's still not very clear how should the :focus state work for the element with display: contents itself. I suppose the easiest way to implement it is to only apply the :focus styles to the element's contents via inheritance. This would mean that the elements with display: contents would not get the default browser "focus ring", but the changes of color, background etc. would be inherited automatically by the element's descendants, and authors would be able to explicitly style the specific descendants of these invisible focused elements.

Another option can be to introduce a new pseudo-element like ::selection that would span all the visible contents of the invisible element and get the default browser focus decoration, so the focus would be always visible, but this approach looks more complicated.

[emilio]

It doesn't make much sense to focus something that doesn't have a box. :hover only works because it's applied to the whole parent chain. That is, comparing :hover and :focus isn't really appropriate. The comparison should be, I think, :hover and :focus-within, which should work with display: contents without issues AFAICT.

[AmeliaBR]

@Emilio The intention of display: contents is that it should only affect layout, not functionality. So we need to consider how it applies to interactive elements, not just container elements.

For example, you might want to switch the appearance of a widget from a drop-down list on small screens to a radio-button style layout on larger screens, by making the container disappear and just laying out the options. However, you would still want the widget container (the element that replaces the role of a <select>) to gain focus (and then use arrows to switch between the options).

Or, you might have a link containing both an image and a text block. For layout purposes, you want to lay out the two parts as independent children of the parent layout context, but they are still a single link for accessibility and function.

(Note: current browser implementations of display: contents fail to live up to this promise. But that's another issue.)

The :focus selector would still match the focused element, so any inheritable changes set on it (like color) would propagate to the children. But as currently defined, and box-based styles on the element itself (like outline) would not apply. Which means that default browser focus styles, and most author-defined focus styles, would no longer be rendered.

---

I like the idea of extending the properties that apply to highlight pseudo-elements to also apply to display: contents elements. The current list of properties in that category are:

• color
• background-color
• cursor
• caret-color
• outline and its longhands
• text-decoration and its associated properties
• text-emphasis-color
• text-shadow

The only ones which apply in a way different from simply inheriting to child content are outline and background-color. Background color is well supported for selections, so should be straightforward to apply to a multi-box collection equivalent to a display: contents element. Outline would need to be implemented in a way that supports more than a simple rectangle, but this is already true for elements with absolute/fixed position children that extend outside of the parent.

[tabatkins]

Whether or not an element is focused has no relation to whether it's in the box tree or not. (It might affect whether some methods of focus-traversal can reach it, but you can always .focus() the element.)

Whether or not the element is display:contents has no effect on how selectors match and properties apply; a focused element will always match :focus if it's focused, and the specified properties will be applied to it. None of them will have any direct effect on the element, because it doesn't generate a box, but inheritance will still work.

We shouldn't try to get extra-smart with this; the element is gone, there's nothing to apply a background or anything else to. (Note, for example, that if you display:contents a child of a grid container, its children are now grid items, and can be moved arbitrarily around the grid; there is nothing remotely related to the "first line" concept to refer to here.)

[SelenIT]

It doesn't make much sense to focus something that doesn't have a box.

Respectfully disagree. If the element is interactive, can get activated and responds to events as usual, and its activation behavior can have a visual effect on its contents, I see no reasons why this element can't get focus. Making the element and all its subtree completely unfocusable just because if is displayed differently (not hidden/removed!) is a real usability problem and very unlikely matches the authors' intent to just change the element's presentation, but not changing its semantics nor behavior. Having some "virtual" focus state for the invisible element that can make visual change through the element's descendants seems to be much less problematic than having the element and its whole visible subtree completely not focusable.

It might affect whether some methods of focus-traversal can reach it

@tabatkins, could you please show an example? The only way how CSS can prevent the visible and otherwise focusable element from getting focus through click/tap I can quickly imagine is pointer-events: none for all its children, but this seems unrelated to display to me. I agree with you that "we shouldn't try to get extra-smart with this", and the example with grid container's "grandchildren" displayed as separate grid items seems not more complicated to me than, e.g., absolutely positioned children of the visually hidden focused elements. CSS already can handle multiple boxes changing their style because of one element getting focused, Does display:contents really add anything new here?

[emilio]

Making the element and all its subtree completely unfocusable just because if is displayed differently (not hidden/removed!) is a real usability problem and very unlikely matches the authors' intent to just change the element's presentation, but not changing its

FWIW, I agree that making descendants not focusable is a bug. I haven't been able to reproduce it in FF Nighly / FF 58, but Chrome does indeed prevent you to tab to stuff in display: contents subtree. I'd file a Chrome bug for that nor Chrome.

(EDIT: I was going to file myself a Chrome bug and couldn't repro anymore, so probably I wasn't testing what I thought I was testing).

[emilio]

It's not clear to me that focusing elements without a box is great in general... It'd be confusing to have to tab twice to get to the <input> in:

<!doctype html>
<div style="display: contents" tabindex="0">
  <input>
  <div tabindex="0">Focused?</div>
</div>

Which UI should the browser show when the display: contents element is focused? Note that it has no box, it's descendants could be anywhere in the layout tree. It seems like a really weird behavior to explain to any user IMO... I could be convinced otherwise I guess.

In any case agreed that we should special-case as little as needed. Special cases = bugs.

[SelenIT]

it has no box, it's descendants could be anywhere in the layout tree. It seems like a really weird behavior to explain to any user IMO...

Completely agree that it's weird. Exactly like so is the focus behavior of, e.g., an off-screen positioned element with on-screen absolutely positioned children, or the focus behavior of the element with good old outline:none and no replacement for it. Sure, it is bad. But, just like in case of outline:none, it can be fixed (by applying special styles to the element's descendants, in this case). Sure, this possibility (as many others in CSS) can have bad effect on the usability, and the spec probably should warn against misusing/overusing it.

But removing the element from the accessibility tree altogether without any possibility to bring its displayed parts back into it, as browsers currently seem to do, looks way more problematic to me, regardless how good the intent of this behavior was.

[tabatkins]

@tabatkins, could you please show an example?

I imagine that display: none on an element prevents it from being tabbed to. display:contents would do the same thing - there's nothing on-screen to be tabbed to!

I agree with you that "we shouldn't try to get extra-smart with this", and the example with grid container's "grandchildren" displayed as separate grid items seems not more complicated to me than, e.g., absolutely positioned children of the visually hidden focused elements.

Note - I was responding to the idea that display:contents elements could still have background work on them, like ::first-line.

[SelenIT]

To me, display: contents and display: none for the interactive element with visible content (e.g. button) are very different. While display: none really removes the element from the presentation, display: contents leaves its children on-screen, they still response to activation via click/tap, and the author most likely wants to preserve all the aspects of their interactivity. The interactive element with display:contents looks very similar to the common pattern for creating custom controls with native functionality: visually-hidden normal <input> + its sibling (usually a <label> or a <span> inside it) that adjusts its styling according to the state of the invisible <input>. The focus state is no different: the <input> elements gets focused by tabbing despite being off-screen, its visible siblings react to this and the user gets the decent UX.

From display:contents, I expect the behavior similar to that. I also expect that the primary use case for applying it to interactive elements would be similar — working around browser limitations of native control styling (e.g. inability to make the <button> non-atomic inline element) while preserving as much native semantics/functionality as possible. It's extremely unlikely that authors expect such elements, which are perfectly visible (through content) and reachable to users, to disappear from the accessibility tree and tabbing sequence.

P.S. Regarding background of these elements, I agree that they shouldn't have it themselves. What I suggested (as a kind of brainstorming-style option) was adding a new pseudo-element (e.g. ::now-focused), which in case of the regular element would match the element's box, and in case of display:contents element would be something ::selection-like that spans all the visible children of such element, and making browsers apply their default focus indication (outline etc.) to this pseudo-element instead of the element. But I admit that this option is not realistic:)

[tabatkins]

That is not what display: contents does or what it's intended to do. It's meant to remove wrapper elements that are added for semantics or scripting purposes, but mess with styling that depends on direct parent/child relationships (like grid container -> grid item).

This is why it's not good for the case you're talking about. For example, as far as CSS is concerned, button is just a specially-styled span; a <button>foo</button> with display:contents is just raw text, not a button at all anymore. (You can still click on the text, and the click event will bubble up to the button element and trigger a button press, but that's because the DOM and the visual display don't have to have any particular correspondence with each other.) The text is not focusable by tabbing in a normal button, and it doesn't magically become tabbable here either.

The input+label example you bring up doesn't apply either; the input is offscreen, but still present in the page, so it can still be tabbed to and focused by user interaction just fine. You just can't click on it because it's not on screen; this is no different from it just being obscured by another element. This is very different from the element not existing in the rendering structure at all.

[SelenIT]

Well, display:contents might be not intended for this, but the problem of styling limitations of native controls still exist and any option to strip off all the "dark magic" from these elements is too tempting. Until browsers offer the better way for this (some new appearance value?), authors would likely use all the available valid CSS means to solve this problem — including display:contents.

I'm OK with button:focus { display:contents } not being highlighted, and with its plain text content not highlighted as well. But I'm not OK with the span inside this button not applying the button:focus > span styles. And I'm very not OK with visible and interactive element that can't be keyboard-activated at all just because of its styling. As an author, I see the focus state as a property of the DOM element, not of a box in a render tree. It's the DOM element, not the box, that fires focus and blur events. And if something is interactive, it's expected to be focusable.

After all, in #2355 we added the following text:

Aside from the none value, which also affects the aural/speech output [CSS-SPEECH-1] and interactivity of an element and its descendants, the display property only affects visual layout: its purpose is to allow designers freedom to change the layout behavior of an element without affecting the underlying document semantics.

Doesn't this imply that the interactive element with no box but with visible children is just the element that can't be styled on focus itself, not the element that magically became not focusable?

[bradkemper]

And I'm very not OK with visible and interactive element that can't be keyboard-activated at all just because of its styling. As an author, I see the focus state as a property of the DOM element, not of a box in a render tree.

Agreed. I would expect the element to be in a focused state, but just not having any visual indication of that state, unless the author picked a descendant element to show an outline (or other distinctive styling).

[FremyCompany]

I think outline should work on display contents elements. Just like it works if an online gets split into lines or bidi or even regions or by a block-in-inline. I think the element should be focusable and tab-focusable too, but only if it is not replaced or a shadow host or none of its descendants in the light tree produce a box. The elements in cases noted above behave as if they were display none and should therefore not be focusable. Besides outline and a few other properties like pointer-event, properties should have no effect on the elements that do generate boxes for their descendants, besides being inherited by default.

[tabatkins]

An inline getting split across lines is still generating fragments - focusing doesn't need to care whether there are 1 or more fragments, it works similarly in either case.

But zero fragments is a very different case. Where is that outline supposed to go??? There is zero promise of content contiguity here; if you display: contents a child of a grid container, the grandchildren can get placed willy-nilly in the grid, while the child has no position at all.

A display: contents element isn't visible. It isn't interactive. It's nothing at all. It just has contents that might be visible and/or interactive.

[FremyCompany]

I think a case can be made here.

Outlines may be non-rectangular. For example, if the element is broken across several lines, the outline should be an outline or minimum set of outlines that encloses all the element’s boxes.

The parts of the outline are not required to be rectangular. To the extent that the outline follows the border edge, it should follow the border-radius curve.

The position of the outline may be affected by descendant boxes.

[FremyCompany]

Now to the question "does the spec say you should have an outline in that case" I'd say probably no. Whether it should say so is another question. You will have to answer these questions anyway when working on exposing these elements to assistive technologies. If these elements are there for semantic purposes, they must be exposed, and you will somehow need to synthetize something for them.

[SelenIT]

A display: contents element isn't visible. It isn't interactive. It's nothing at all. It just has contents that might be visible and/or interactive.

I guess this is 100% true from the (current) implementer's perspective, but not from the user's. If something is nothing at all, it can't have any visible/interactive parts at all. If the user sees and interacts with something, it can't be nothing — it actually is the visible and interactive element that can only be partially hidden. Even if its main part is hidden, the one that gets the focus outline. That's why it's OK for me if such element can't be styled directly on focus — it's really nothing to be styled directly — but it's not OK to have no focus state for it (that I could use to style its visible descendants) at all.

But zero fragments is a very different case. Where is that outline supposed to go???

With all due respect, I can't agree with treating the visible part of the display: contents element as "zero fragments". I think of ::selection as the closest existing thing. At least, the text content of the display: contents element can be selected, and these non-zero selected fragments can be styled somehow. So I suggested a new pseudo-element (something like old Mozilla's ::-moz-focus-inner, maybe?) that would span all these fragments, so you would be able to apply the outline to it. But I could live without it, as long the element itself stays focusable in principle.

Maybe it would be better to make this pseudo-element proposal a separate issue, and focus on the focusability of the display: contents element itself here?

[tabatkins]

If something is nothing at all, it can't have any visible/interactive parts at all.

Yes, and that is exactly the case here. There is absolutely no visible/interactive parts of the element on the screen. It's children are visible, but that's something entirely different. display:contents, insofar as possible, makes it so that the element was never in the page at all. (It exists so you can add wrappers for scripting or a11y purposes that aren't intended to show up in the page itself.)

As far as CSS is concerned, there is literally nothing there.

[SelenIT]

Functionally, the element subtree is clearly the part of the element: it passes the events to the element, it inherits the CSS properties where possible, and it triggers the element's activation behavior. The only thing that display: contents changes (to literally nothing) is just one box in the box tree, the box of the element itself. But for the user, there is no difference between "clicking the button" and "clicking the button contents", as long as they result in the same action. This is already the case in current implementations. And it should be, because

the display property only affects visual layout

and not the interactivity of the element and its descendants (with the one and only exception for the none value).

In my opinion, we should find the way to preserve the states of the boxless active elements that the user can interact with trough their subtree. Although technically it's a new problem for CSS, functionally it reminds me much of the case of visible labels for off-screen controls I mentioned before.

[fantasai]

Wow, ok, so my conclusion about all this is the following:

• Elements that have 'display: contents' can still be focused (e.g. through Element.focus()), and will be selected by the :focus selector, as usual. I think the specs are clear about this.
• Whether a particular user interaction focuses the element is undefined and up to the UA and can depend on the type of interaction. However, to the extent that interacting with a descendant of the element would normally focus the element even if their respective boxes were disjoint, it should be focused.
• Backgrounds and borders definitely do not apply to elements that have 'display: contents' as there is no box for them to apply to.
• Whether 'outline' can apply to 'display: contents' elements is an interesting open question, because 'outline' is defined to be able to draw around descendants, not just the box itself. So the outline can exist without the element's own box existing. We should probably file this as a separate issue against css-ui×css-display.

Is there anything else I missed here?

[Loirooriol]

Elements that have 'display: contents' can still be focused (e.g. through Element.focus())

@fantasai I'm not that sure about this. An element with display: contents generates no box, thus it's not being rendered, thus most conditions for being a focusable area don't apply. So the focusing steps used by focus() may be aborted.

[emilio]

Note https://github.com/whatwg/html/issues/3947 too, regarding that :)

[emilio]

Though for focus() Gecko at least does abort when the element is display: contents.

[SelenIT]

An element with display: contents generates no box, thus it's not being rendered,

Respectfully disagree. "Doesn't generate a box" !== "doesn't have any associated CSS layout boxes, SVG layout boxes, or some equivalent". If, e.g., the ::before and ::after pseudo-elements boxes are not associated with the originating element, it would be super strange from the author's perspective. I'd argue that the text run generated by the element's bare text should probably also be considered "some equivalent" of the CSS box for that purpose. The definition of the "rendered element" in HTML clearly was created before display:contents was introduced, but at least I clearly read it as "if element has any visible parts", and I can't agree that the content of the element is not its part. Probably that HTML definition should be also clarified further?

[Loirooriol]

the ::before and ::after pseudo-elements boxes [...] the text run generated by the element

@SelenIT My understanding is that the boxes generated by ::before and ::after are associated with the pseudo-element itself, and not directly with its originating element. And a text run is associated with the generating text nodes, and not directly with their parent element.

The definition of the "rendered element" in HTML clearly was created before display:contents was introduced

This is a fair point which should be addressed in @emilio's issue. But currently I don't think "the specs are clear about this" [an element with display: contents being focusable] as @fantasai says.

[SelenIT]

Currently, the spec is pretty clear that

The display property has no effect on an element’s semantics... Aside from the none value, which also affects the aural/speech output and interactivity of an element and its descendants, the display property only affects visual layout.

So if display: contents would affect the focusability of the element, it should at least be also listed as an exception, along with display: none. I'd argue that even affecting particular interactions (like making the element unreachable for the keyboard activation) should be explicitly listed as such exception (though I still hope that having such change in behavior just because of display change is not inevitable).

After re-reading the introduction part of the CSS Display, I have to admit that my understanding of CSS boxes generated by the pseudo-elements and text content as "associated" with the originating element was probably wrong (though using the more unambiguous wording in the HTML spec would still be less confusing:). However, the concept of pseudo-elements that are rendered despite their originating element being not rendered still seems very counter-intuitive to me.

More importantly, since the contents of the element with display:contents can be interacted with in a way that normally makes the element focused (e.g. clicked), from both user's and author's perspective such element definitely has parts of the element that could be a focus target, which fits well the definition of the focusable area. "Magically" making these parts non-focusable just because the element with its subtree is rendered differently seems to violate the Priority of Constituencies principle. That is the reason why I would still prefer considering display:contents a very special case of the off-screen rendering rather than a strange case of being not rendered (but still displayed and interactive, at least partially!). In my opinion, it would be less confusing and "paradoxical" if the term "not rendered" is used only when the element and its subtree are completely and irrevocably removed from the visual presentation, like with display: none.

By the same reasoning, I'd prefer the focusability (and, ideally, the default focus selection) of the element being associated not with its primary box in the CSS box tree, but with the DOM element itself, and automatically (not "magically":) translated to the first displayed part of the element subtree (so the user would be able to tab to the button text, and this text would get the outline similar to the outline of the text link). But I agree that it's probably a separate issue, less important than the question if elements with display:content are focusable at all.

[alice]

From an accessibility point of view as well, if "[t]he display property has no effect on an element’s semantics" is intended to mean that the element is still exposed in the accessibility tree, then making it unfocusable with no way to make it focusable again makes it more difficult to use for assistive technology users, who often rely on keyboard interactivity.

[ExE-Boss]

I believe that display: contents; shouldn’t affect focusability.

[FremyCompany]

@ExE-Boss Same here. It should be focusable, and an outline should be drawn around the boxes generated by its descendants.

[fantasai]

So we've got https://github.com/whatwg/html/issues/1837 filed against HTML about the definition of “being rendered” and https://github.com/w3c/csswg-drafts/issues/3323 filed against css-ui about outlines.

Afaict there's nothing that needs editing in css-display-3 itself. @SelenIT, am I missing anything?

[SelenIT]

I still would be very grateful if the spec would unambiguously answer whether the otherwise focusable element should be tabbable or not. If the definition of "being rendered" will be updated to treat elements with display:contents as rendered, would the current spec be enough to answer "Yes, it should", so we would be able to file relevant bugs for browsers?

[fantasai]

Spec currently says

The display property has no effect on an element’s semantics: these are defined by the document language and are not affected by CSS. Aside from the none value, which also affects the aural/speech output [CSS-SPEECH-1] and interactivity of an element and its descendants, the display property only affects visual layout: its purpose is to allow designers freedom to change the layout behavior of an element without affecting the underlying document semantics.

and also wrt 'contents' specifically

Note: As only the box tree is affected, any semantics based on the document tree, such as selector-matching, event handling, and property inheritance, are not affected.

Tabbing to an element qualifies as interactivity and event-handling. So I think the spec is OK. WDYT @SelenIT ?

[SelenIT]

@fantasai, I have always read these notes exactly this way (display:contents shouldn't prevent element from being tabbed to), but @tabatkins insisted that

It might affect whether some methods of focus-traversal can reach it

so I decided that more clarification is needed.

Do we now have consensus that display:contents shouldn't affect any methods of focus-traversal?

[FremyCompany]

@SelenIT I don't think that's the case, at least as strongly as you suggest. I think there is consensus that it shouldn't affect anything as long as at least one descendant of the element is rendered. If both the element and all of its descendants are rendered, there is nothing to focus on.

But that is a question for the HTML spec, not CSS. CSS is as precise as it can be. CSS does not define tab-navigation order, HTML does.

[SelenIT]

it shouldn't affect anything as long as at least one descendant of the element is rendered

@FremyCompany, I agree that in ideal world it should be so, but in the same time try to avoid introducing complex heuristics ("being extra smart", as @tabatkins has put it). If it would be easier for implementers to always treat elements with display:contents as kind of offscreen-rendered rather then switch between treating them as rendered or non-rendered depending on other conditions, I would rather go with this. At least, it's easier to remove the otherwise tabbable element from the tab sequence if authors want to (tabindex="-1") than the other way around.

And since the HTML definition of focusability is based on the "being rendered" concept, and the latter refers back to CSS box tree, I'd like to double-check that current CSS definition can't justify the understanding of "being (not) rendered" that I can't agree with.

[annevk]

@fantasai hmm, if there's no box though the user won't have anything to click on, so it'll definitely affect event handling to some extent (at least as much as display:none affects it). And focus also generally operates on (or uses) the box tree as I understand it so that'll also be affected.

[SelenIT]

There is no box of the element itself, but there are boxes of its contents/pseudo-elements which the user can click on (and thus activate the element through event bubbling). From both user's and author's perspective, it's fundamentally different from display:none and is much more similar to offscreen rendering. And that's exactly the reason why tying focus to box tree is probably not the ideal solution since display:contents was introduced.

[annevk]

If a browser uses the box tree and there's no box for this element, it won't be found. So it's quite the same in that regard.

[SelenIT]

Yes, but that't exactly what I (and apparently many others) would like to change.

[annevk]

I don't see how that's doable without it generating a box.

[MatsPalmgren]

Fwiw, I don't really see a problem with including display:contents elements in keyboard navigation from an implementation POV, in Gecko. We can't render anything that requires a box (such as an outline), but that's a separate issue.

[annevk]

I don't think that's a distinct issue necessarily (accessibility of focusable items is important). If we change the approach here it'd really have to be more detailed, including giving HTML the appropriate hooks to make this kind of setup work and probably patching HTML to proof that it's feasible from a standards perspective.

[FremyCompany]

@annevk I'm not sure what you think needs to be changed in the HTML spec, could you clarify?

As far as I'm concerned, there is no need to change anything there; an element that has an associated layout box should be focusable, and nowhere in the spec it is said that the box(es) an element is associated with cannot be the box(es) of its descendants. I don't think it makes a lot of sense to argue that an element should be considered "not rendered" while its children are considered "rendered".

[annevk]

Basically wherever it says "box" (usually as CSS box, layout box, or being rendered) there might have to be changes to account for this novel way of determining things. E.g., with your definition if I appended a text node child to an img with display:contents, it'd affect the calculation of width and height somehow (not sure how).

[FremyCompany]

@annevk Ah, you are just saying we should review the spec just to be sure, yeah that makes sense to me.

For your specific case though, you don't have to worry, replaced elements handle display:contents as a synonym of display:none so the children of the img will remain unrendered.

Details are here: https://www.w3.org/TR/css-display-3/#unbox

[fantasai]

@SelenIT @FremyCompany Afaict, there's nothing left for us to do here, so closing out per https://github.com/w3c/csswg-drafts/issues/2632#issuecomment-438851770 and https://github.com/w3c/csswg-drafts/issues/2632#issuecomment-493249786.

[dbaron]

I've written (but not yet merged) a change to Chromium to do this, that is, to make elements with display: contents focusable.

I'm somewhat concerned about landing it given that there seems to be some resistance from other implementors. It's not clear to me whether other implementors are actually willing to make this change, and I think it would be good to find out before changing Chromium to diverge from a currently-interoperable behavior.

However, I agree that that currently interoperable behavior is bad. It's important that the resolutions of #2355 and of this issue be consistent, since (as I understand things) part of the contract of reporting to assistive technology that an element has a particular role is that this exposure implies that the element should also have the keyboard behaviors associated with that role (which admittedly not all roles have, but many do). So I think we should either change our resolution of neither issue (which implies that implementations need to change on focusability), or change both (which I think implies implementations need to change AT exposure).

I'm curious whether others think that this issue should be reopened in order to build stronger consensus around the correct behavior here.

[dbaron]

Just to add a little bit more detail about the idea that ARIA roles and keyboard behavior should match: this is documented pretty clearly in the author-focused guidance in https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/ but I think that guidance also applies to the design of browser engines (which that guidance effectively assumes do things correctly).

[dbaron]

FYI, some followups that resulted from this include whatwg/html#9425 and the position requests and bugs linked from it.