Testing Orca screen reader in openQA - help wanted

Platform Core
1

Hello,
We are extending the GNOME OS openQA tests to cover Orca and there is some strange behaviour happening in the openQA VM. Maybe an Orca expert can help us figure out what is wrong.

Running GNOME OS in a regular VM shows the screen reader working as expected, I press super-alt-S and a voice announces “Screen reader on”.

Recreating that in openQA we see a different behaviour. The test is supposed to do this (see here):

  • Enable audio capture
  • Press shift-alt-S
  • Wait 10 seconds
  • Check the captured audio

I would expect the captured audio to say “Screen reader on”, but something else happens. Looking at the speech dispatcher log I can see this sequence of events:

  • Orca sends “Screen reader on”
  • One second later, it cancels that and sends something like “29 push button”

Here’s an example of the audio capture: openQA: gnomeos-master-iso-x86_64-gnome_accessibility@qemu_x86_64 test results

Any idea what could cause this ? Presumably some unwanted input event is happening, but it’s hard to know what.

Thanks
Sam

2

I believe this is the expected behaviour. At least orca is doing the right thing here.
When I login to my gnome desktop orca says Screen reader on and then 03 push button. 03 pushbutton is presentation of the selected button in the gnome shell calendar widget.
Is the calendar showing on your desktop? Is something focused when doing this locally? I think this is only happening when there is nothing else to focus.
If this is going to be classified as a bug then I guess gnome shell should be looked into.

3

Does it finish saying “Screen reader on” in your case ?

The calendar isn’t showing but that would explain where “29 push button” comes from.

Maybe the best thing is to start an app in the test so there is something to focus on - will try that :slight_smile:

4

Hello,
That might actually depend on how TTS speech rate is setup. On mine it manages to finish speaking Screen reader on message. I have got it set at 85% in the screen reader preferences window. The default speech rate is much slower and I think it is verry likelly to get interupted by that event related to the button presentation.
I think in the real life people are used to the fact some prompts might be cut off with other more important phrases. In fact I would consider this a feature not a bug.
For example now while I am writing this reply in the firefox window I can quickly navigate over the text line by line by pressing up or down arrow key. When orca is reading a line and I don’t wish to read it fully to the end I can press arrow key interrupt the reading and continue reading the next line.

Greetings

Peter

5

This is useful to know. I was wondering if “Screen reader on” was the most important thing for us to be testing or if we can do more realistic test.

However we do need the spoken output to be reproducible, which the calendar is not as the day changes every day. Hopefully starting an app will at least give us a consistent speech output we can use in the test.

6

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.