[css-display][css-aam] Is the 'display' value supposed to affect the semantics exposed to screen readers? #2355
Comments
|
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. |
|
So maybe CSS Display should explicitly state somewhere that the |
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. |
|
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
changed the title
fantasai
added
css-display-3
|
OK, I added an advisement to the 'display' property definition to clarify this point:
Let me know if you have suggestions on further improving the wording here. |
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. |
|
But I agree with the rest of your note. |
|
@bradkemper OK, edited to say
|
|
The Working Group just discussed
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 |
fantasai
added
Closed Accepted by CSSWG Resolution
and removed
Commenter Response Pending
labels
|
It has been reported that |
|
@SelenIT I would say that is also a bug. |
Adrian Roselli recently raised the very important issue that setting non-table
displayvalue to HTML<table>element, as well as settingdisplay:tableto 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
displayvalue. Unfortunately, there is apparently no data about how this behavior helps users (if at all).Shouldn't the effect of changing the
displayproperty 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
displayvalues and aural styles in the introduction.The text was updated successfully, but these errors were encountered: