After https://trac.webkit.org/changeset/207280 the following accessibility tests fail on the platform GTK: Regressions: Unexpected text-only failures (3) accessibility/meter-element.html [ Failure ] accessibility/roles-computedRoleString.html [ Failure ] accessibility/roles-exposed.html [ Failure ] The diffs: https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20%28Tests%29/r207280%20%2818795%29/accessibility/meter-element-pretty-diff.html https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20%28Tests%29/r207280%20%2818795%29/accessibility/roles-computedRoleString-pretty-diff.html https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20%28Tests%29/r207280%20%2818795%29/accessibility/roles-exposed-pretty-diff.html
<rdar://problem/28752892>
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.