[css-display][css-aam] Is the 'display' value supposed to affect the semantics exposed to screen readers?

[SelenIT]

Adrian Roselli recently raised the very important issue that setting non-table display value to HTML <table> element, as well as setting display:table to other elements than <table> , can affect the way these elements are presented to the screen readers (and thus should be avoided).

For me, this seems to be directly contradicting to the purpose of CSS in terms of the Separation of Concerns principle (at least, as I always understood it). For me, one of the biggest advantages of CSS is being able to express any meaning with proper markup in HTML without need to change the presentation, and vice versa. I used to think of the possibility to get the table-like look without adding table semantics in certain circumstances, or improving the visual layout of the data table with CSS Grid formatting options not available for the CSS Table visual model, as a great Progressive Enhancement feature. As an author, I hope that the semantics of my code is defined by the markup part, and styling shouldn't affect it (at least, not that much).

So, for me, this behavior of the browsers and screen readers feels like a bug. There are some bugs about this filed for Firefox ([1], [2]), one of which has been resolved already, and in the discussions under these bugs there seems to be the agreement that in general authors don't want the meaning of the markup change because of the display value. Unfortunately, there is apparently no data about how this behavior helps users (if at all).

Shouldn't the effect of changing the display property on the semantics — or the absence of such effect
— be specified anywhere, in order to improve web interoperability and reduce confusion in the future? I guess that the best place for that would be the CSS Display spec, which already briefly mentions some interaction between the display values and aural styles in the introduction.

[FremyCompany]

No, this is a bug. It just happens that is is a very common bug, because computing table semantics usually requires running the table layout, which browsers don't do if the table isn't display:table. But in theory, we should have an alternate codepath for all role=table and do something useful with that, it's just that most browsers haven't implemented that properly because of time constraints.

[SelenIT]

So maybe CSS Display should explicitly state somewhere that the display property isn't meant to affect the semantics of the elements, to make it more clear for browser vendors that the opposite behavior is a bug?

[FremyCompany]

So maybe CSS Display should explicitly state somewhere that the display property isn't meant to affect the semantics of the elements

display:none makes an element disappears and changes semantics though

that behavior is defined very clearly in aria specs, it is not clear why anyone would think changing semantics makes sense in other cases; I don't think we have a spec problem here, we just have a resource priority problem. Not opposed to a note, but that won't change UA behavior for tables any time soon.

[AmeliaBR]

I think the most logical place for clarifying this would be the CSS-AAM: https://github.com/w3c/css-aam/

(Which is currently just a stub spec, I don't know if anyone is working on it at all, but the idea was that it would document all cases where CSS properties need to be reflected in the accessibility tree.)

[fantasai]

OK, I added an advisement to the 'display' property definition to clarify this point:

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 aural/speech output [CSS-SPEECH-1], 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.

Let me know if you have suggestions on further improving the wording here.

[bradkemper]

Aside from the none value, which also affects aural/speech output

It affects more than that. Since it suppresses box generation, it also prevents focusing the element or its descendants. This is actually an important a11y effect too, even for non-visual layout.

[bradkemper]

But I agree with the rest of your note.

[fantasai]

@bradkemper OK, edited to say

Aside from the ''display/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

[css-meeting-bot]

The Working Group just discussed Clarify (non-)effect of 'display' on document semantics and assistive technology, and agreed to the following resolutions:

• RESOLVED: Keep this note in Display L3

The full IRC log of that discussion

<dael_> Topic: Clarify (non-)effect of 'display' on document semantics and assistive technology
<AmeliaBR> florian, yes, I'll do that.
<dael_> github: https://github.com//issues/2355
<fantasai> https://github.com//issues/2355#issuecomment-375084853
<dael_> fantasai: This is about adding a note to explain display propertie doesn't effect semantics. I was asking for WG review of the note text. Let me know if there are changes to suggest.
<dael_> florian: I agree witht he note but I'm surprised it's needed. If I understand it's a note because browsers do mess it up.
<dael_> fantasai: They acknolwege this is a bug.
<dael_> florian: We're not stuck for compat?
<dael_> fantasai: Everyone agrees it's a bug, it jsut hasn't been a prioerity.
<dael_> florian: Good.
<dael_> astearns: I guess there is no linkable bit in the spec to this note.
<astearns> https://drafts.csswg.org/css-display-3/#the-display-properties
<dael_> astearns: This section^ This is the section the note is in. But there's no way to link to just the note in the bit.
<dael_> fantasai: I can give it an anchor.
<dael_> astearns: I don't know it's necessary. Just trying to get text into the minutes.
<dael_> fantasai: It's quoted in the comment
<fantasai> 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
<fantasai> without affecting the underlying document semantics.
<dael_> astearns: Any other opinions or concerns about this note?
<dael_> astearns: Prop: keep this note in display L3.
<dael_> astearns: Objections?
<dael_> RESOLVED: Keep this note in Display L3

[SelenIT]

It has been reported that display contents also affects the ability of the element to be the anchor target. If this behavior is intended and consistent across implementation, maybe it's also worth noting there?

[bradkemper]

@SelenIT I would say that is also a bug.