Re: [orca-list] Orca within Google forms as rendered by Firefox

*might* be Orca-related.

Google code is terrible stuff. But what they're doing here, while gross,
is legal so far as I can see.

They're using material design which requires some funky visual styles.
So instead of using real radio buttons, they've got huge steaming piles
of divs. But the divs have role="radio" and some other stuff like
posinset. There's a div surrounding the group of radios with a
radiogroup role (this all imitates a fieldset with real radio inputs).
The only thing that seems missing is, because these are divs, they don't
have name attributes. I'm not sure what Orca cares about but I happen to
have run into issues from the aXe testing tool which not only checks the
roles of things claiming to be radios and not only checks that they are
in a group, but also checks they have matching name attributes. Which
only inputs have and these are imitating inputs so, no matching name
attrs. Not sure if that matters to Orca.

My best guess then is that Orca might be getting tripped up by code
that's trying hard to imitate radio buttons using pure aria. Joanie'd
know for sure I think.


On Sat, Jun 10, 2017, at 08:56 AM, Shérab wrote:
Dear all,

I observe a behaviour I do not understand on forms like

After the introductory page, one gets pages with radio buttons.

On these pages, the 'r' key correctly goes from radio button to radio

But when browsing the document, the objects are shown but not identified
as radio buttons.

I am wondering where the problem comes from. Is it Google's code which
is not conform to the accessibility standardds or is the problem more
Firefox or Orca related?


orca-list mailing list
orca-list gnome org
Orca wiki:
Orca documentation:
GNOME Universal Access guide:
Log bugs and feature requests at

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]