Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
SelenIT opened this issue Feb 23, 2018 · 11 comments

Comments

@SelenIT
Copy link
Collaborator

@SelenIT SelenIT commented Feb 23, 2018

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
Copy link
Contributor

@FremyCompany FremyCompany commented Feb 25, 2018

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
Copy link
Collaborator Author

@SelenIT SelenIT commented Feb 26, 2018

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
Copy link
Contributor

@FremyCompany FremyCompany commented Feb 26, 2018

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
Copy link
Contributor

@AmeliaBR AmeliaBR commented Feb 26, 2018

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.)

@SelenIT SelenIT changed the title [css-display][css-tables][css-speech] Is the 'display' value supposed to affect the semantics exposed to screen readers? [css-display][css-aam] Is the 'display' value supposed to affect the semantics exposed to screen readers? Feb 27, 2018
@fantasai
Copy link
Collaborator

@fantasai fantasai commented Mar 21, 2018

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.

@fantasai fantasai added the Agenda+ label Mar 21, 2018
@bradkemper
Copy link

@bradkemper bradkemper commented Apr 4, 2018

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
Copy link

@bradkemper bradkemper commented Apr 4, 2018

But I agree with the rest of your note.

@fantasai
Copy link
Collaborator

@fantasai fantasai commented Apr 4, 2018

@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
Copy link
Member

@css-meeting-bot css-meeting-bot commented Apr 4, 2018

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
Copy link
Collaborator Author

@SelenIT SelenIT commented Apr 5, 2018

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
Copy link

@bradkemper bradkemper commented Apr 5, 2018

@SelenIT I would say that is also a bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants