Hello Joanie,
Sorry for my spam related to this however I have discovered we are missing something.
These table rows are correctly being presented as clickables. These are also displayed in the list of clickables.
However finding a clickable in the list and hitting activate does nothing on these table rows.
I haven't figured out more yet.
Greetings
Peter
Hello,
It might be doable to add a unbound script that will either click the active object if clickable or descend its ancestry to find out nearest clickable parent and perform the click.
Originally I've assumed such functionality is not needed as flat review mouse emulation is very usefull and getting better and better but this will also work on wayland and consider a case where container is clickable rather than the element with the actual content.
These container elements have just recently been removed from the flat review presentation that makes the flat review output even more awesome to read.
That is something I like as well.
I apologize to Nolan and all other people who have requested this feature in the past and I have commented against it.
Greetings
Peter
Dňa April 24, 2019 7:33:00 AM UTC používateľ "Arkadiusz Kozioł" <zywek-mailing nvps pl> napísal:Is it possible to do click this object such as in nvda, withour pressing alt+shift+a and hit Activate button?
W dniu 23.04.2019 o 22:36, Peter Vágner via orca-list pisze:
Hello,
Sometimes I am coming up with strange web authoring issues captured from the wild of the web.
Now it's another of such a rare moments.
Sometimes web app authors tend to use HTML tables instead of lists to create multi column list like widgets.
When they are creating such widgets it's still quite common that keyboard access ends up not implemented.
With such a widget table rows are resembling items of an interactive list. Clicking the table row either selects the item or activates it.
What I have just found out is that orca does not list clickable table rows and possibly another page elements as clickables. And it neither presents these in the list of clickable elements.
When considering clickables orca examines if an object is not focusable and is not a so called focus mode widget.
Typical focus mode widgets are text entries, comboboxes, list boxes, slider, spin button and similar. These are easy because their are usually actionable from the keyboard out of the box.
When looking at orca web script utilities, Table cell, table row and list item are also focus mode widgets. Most likelly I can't imagine all the use cases my-self and I can't describe why that is a good idea.
However these should only be considered focus mode widgets when they either receive focus or claim that their are able to receive focus.
When this is used for switching focus vs browse mode after receiving an event this is all fine.
However when looking for clickables we are currently looking for not focusable objects as well as for objects that are not focus mode widgets.
I think this needs reconsideration because if a widget can be considered focus mode widget it should be focusable and keyboard controllable. And when looking for clickables we are naturally looking for not focusable elements.
I know this needs more thinking however I'd like to be able to click on such clickable table rows in the online banking web app I am currently using it's why I have started this.
I have attached a little example document showcasing what I am looking for.
Can this be reconsidered or can you suggest something else?
I know this is perhaps very rare and is certainly an authoring issue rather than orca issue however it really drives me crazy when paying my bills each month.
I have already contacted my bank technical support about this however nothing has changed for a few months so I'm trying my luck here.
BTW a lot of people in the central europe might be affected by this. At least this banking app called George is knowingly being used in Slovakia, Czech republic, Austria, Romania and Croatia and perhaps more countries to follow.
Unfortunatelly accessibilitywise it has a lot of unimplemented features i.e. menus do have aria markup but lack keyboard controls. Form navigation is altered significantly. Links and buttons are not activatable via the keyboard. Some decorative images have text descriptions and interactive image controls may miss those and similar.
Heh but look at their web site how cool their marketing looks like :P https://george-labs.com/
Most of its defects can be worked around by existing orca features however I am unable to compensate for that broken accessibility implementation of their transfers list using HTML table with clickable rows under the hood.
Excuse me for the rant and thanks for the help.
Greetings
Peter
_______________________________________________ orca-list mailing list orca-list gnome org https://mail.gnome.org/mailman/listinfo/orca-list Orca wiki: https://wiki.gnome.org/Projects/Orca Orca documentation: https://help.gnome.org/users/orca/stable/ GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html Log bugs and feature requests at http://bugzilla.gnome.org
--
Odoslané z môjho Android zariadenia prostredníctvom K-9 Mail. Prosím, ospravedlňte moju stručnosť.
_______________________________________________ orca-list mailing list orca-list gnome org https://mail.gnome.org/mailman/listinfo/orca-list Orca wiki: https://wiki.gnome.org/Projects/Orca Orca documentation: https://help.gnome.org/users/orca/stable/ GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html Log bugs and feature requests at http://bugzilla.gnome.org