Open Bug 1487110 Opened Last year Updated Last year

Add support for CSS styled fieldset/legend boxes?

Categories

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

enhancement

Tracking

()

People

(Reporter: mats, Unassigned)

References

(Depends on 1 open bug)

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
You need to log in before you can comment on or make changes to this bug.