Summary: | [GTK] Meters are inaccessible after r207280 - could be fixed by supporting meters in RenderThemeGtk | ||
---|---|---|---|
Product: | WebKit | Reporter: | Carlos Alberto Lopez Perez <clopez> |
Component: | Accessibility | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW --- | ||
Severity: | Normal | CC: | bugs-noreply, jdiggs, koivisto, mario, tyler_w, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Bug Depends on: | |||
Bug Blocks: | 163212 |
Description
Carlos Alberto Lopez Perez
2016-10-13 04:30:21 PDT
Committed r207283: <http://trac.webkit.org/changeset/207283> I did a bit of digging into this. Since the change in question, if the platform's RenderTheme does not support meter, HTMLMeterElement::createElementRenderer() will not create a RenderMeter. WebCore Accessibility for meters currently assumes we have a RenderMeter. So either we need to make change in how WebCore Accessibility does its thing, or RenderThemeGtk needs to start supporting meter. Because I am completely RenderTheme ignorant, I don't know how easy doing the latter would be. But a quick test (having createElementRenderer() return a RenderMeter despite the fact that RenderThemeGtk doesn't support it) caused meters to become accessible again via ATK/AT-SPI2. After https://bugs.webkit.org/show_bug.cgi?id=232569, you can now create an AccessibilityProgressIndicator with any type of renderer generated from a meter or progress element, so might be worth seeing if these tests pass in GTK now. |