Open Bug 1487110 Opened 6 years ago Updated 2 years ago

Add support for CSS styled fieldset/legend boxes?

Categories

(Core :: Disability Access APIs, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: MatsPalmgren_bugz, Unassigned)

References

Details

FYI, bug 1483787 will implement some CSS property values to trigger fieldset/legend box layout on any element. Likewise, to suppress that layout on HTML fieldset/legend elements by setting the property value to none. (currently, the proposed CSS is -webkit-appearance:fieldset/fieldset-legend) We might want to consider if this should have any effect on the accessibility tree at all. (e.g. creating a HTMLLegendAccessible for a "rendered legend" even when it's not a HTML legend element) The draft spec is here https://whatpr.org/html/3934/rendering.html#the-fieldset-and-legend-elements There's an interoperability overview document here https://docs.google.com/document/d/1yFUy8pBQUVWtOP8O7ZDp2wlGdv8KLl7ygXsxoOXNE7o/edit?usp=sharing that briefly discuss accessibility under "Accessibility Issues".
Thanks for the heads up, Mats! Recent community push and real world use cases have caused us to re-evaluate the extent to which CSS should affect the accessibility tree. For example, display: contents no longer affects accessibility semantics (bug 1455357), nor does display: block on tables (bug 1005271). Based on this precedent, I would suggest that: 1. -webkit-appearance: none should *not* remove a11y semantics on <fieldset> and <legend>. 2. -webkit-appearance: fieldset/fieldset-legend should *not* create fieldset or legend semantics for accessibility. Marco, do you agree with this thinking? Looking briefly, it looks like we should be good here for legend (since that's in MarkupMap). However, fieldset seems to depend on the frame type, so we'll probably need to move this into MarkupMap.
Flags: needinfo?(mzehe)
Agreed.
Flags: needinfo?(mzehe)
> 1. -webkit-appearance: none should *not* remove a11y semantics on <fieldset> and <legend>. > 2. -webkit-appearance: fieldset/fieldset-legend should *not* create fieldset or legend semantics for accessibility. I agree with this. Especially (1) because the point is to allow other styling without changing the accessibility, but I think (2) follows. A separate but related analysis about accessibility for fieldset/legend: https://github.com/w3c/html-aam/issues/145
We can use display: contents to confirm the work that needs to be done here (since that effectively removes styling from the equation). (In reply to James Teh [:Jamie] from comment #1) > Looking briefly, it looks like we should be good here for legend (since > that's in MarkupMap). data:text/html,<fieldset><legend style="display: contents;">foo</legend></fieldset> The fieldset does get labelled by the legend as it should. > However, fieldset seems to depend on the frame type, > so we'll probably need to move this into MarkupMap. data:text/html,<fieldset style="display: contents;"><legend>foo</legend></fieldset> An accessible doesn't get created for the fieldset. So, yes, we'll need to move this into MarkupMap. We should add tests for these cases, plus tests for the new -webkit-appearance stuff once bug 1483787 lands.
Is it possible to test this in wpt? I have a work-in-progress PR at https://github.com/web-platform-tests/wpt/pull/12691
Fieldset has been added to the MarkupMap in bug 1508935, which just landed on Autoland. Jamie confirmed in the associated Phabricator thread that that fixes this bug. So the only remaining tasks are to add the tests once bug 1483787 is fixed.
Depends on: 1508935
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.