VO Bot Feedback: Extra spaces in output - "Navigate forwards into a radio group where no radio buttons are checked" (Radio Group Example Using Roving tabindex, Test 1, V24.12.12)

[jha11y]

Description of Behavior

The VO bot output text has lots of extra space characters.

My VO outputs:

Regular crust, radio button, 1 of 3
You are currently on a radio button, 1 of 3. To select this option, press Control-Option-Space.

VO Bot output:

Regular crust
radio button, 1 of 3
You are currently on a radio button, 1 of 3. To select this option, press Control -Option -Space.

Test Setup

• Test File: test-01-navForwardsInToRadioGroupWhereNoRadioButtonsAreChecked-voiceover_macos.collected.html
• AT: VoiceOver for macOS (Version 15.1)
• Browser: Safari (Version 18)

[css-meeting-bot]

The ARIA-AT Community Group just discussed Issue 1171 - VO Bot output has extra spaces.

The full IRC log of that discussion

<jugglinmike> Topic: Issue 1171 - VO Bot output has extra spaces
<jugglinmike> github: https://github.com//issues/1171
<jugglinmike> scribe+ ChrisCuellar
<ChrisCuellar> jugglinmike: The issue Joe raise is about how the output he reported varies in subtle ways from the VO bot. Based on the use of spaces and new lines
<ChrisCuellar> jugglinmike: I wanted to bring this to the fuller group to understand how the bot should behave. I don't know what the significance of new lines and spaces are. Maybe we all could define some heuristic together
<ChrisCuellar> jugglinmike: For example, if you look at the example, should we consider 2 responses that look mostly the same as the same response. This might be an issue for 2 different human reporters too, so that might not be just a bot issue.
<ChrisCuellar> Matt_King: It's important to distinguish if outputs change over time and across AT version. The other time this matters is when we're display the output (for example in the test runner, etc). So if we're doing normalization, there's some interesting consequences if we normalize input into a text box in a certain way.
<ChrisCuellar> jugglinmike: I was thinking about displaying what people actually type. But also for the sake of transparency, but also surfacing a normalized version. So that testers can compare their raw output vs the normalized output.
<ChrisCuellar> Matt_King: Maybe anything that's a report, we always show the normalized output. But we can always make the raw human input also available. But for the runner, we shouldn't do normalization.
<ChrisCuellar> Matt_King: Is there a decision we need to make about what we ask testers to do? We might not to, if we agree on a normalization algorithm.
<ChrisCuellar> jugglinmike: I think so. This came up in internal conversations. Maybe we set the rule to match what's in the voiceover history. But I don't know what exactly the VO rules are for how they render text output. And I'm not sure Apple can commit to stable output either. So I wouldn't want to lead with that.
<ChrisCuellar> jugglinmike: Bocoup can put together a proposal for this. We'll take this as an action item
<ChrisCuellar> Joe_Humbert: I filed another issue about radio buttons. There's an issue with a disappearing header making the requested command incorrect
<ChrisCuellar> Matt_King: This is a problem. We can't have the tests mismatch
<ChrisCuellar> Joe_Humbert: Back to the extra space, it makes it difficult for me to edit the output if there's unnecessary new lines and trailing spaces. Like 50-60 trailing spaces between new lines.
<ChrisCuellar> Joe_Humbert: This wasn't visually rendered on Github
<ChrisCuellar> Joe_Humbert: The problem seems to be somewhat random
<ChrisCuellar> jugglinmike: I think we can still move forward with a normalization solution
<ChrisCuellar> scribe+ jugglinmike
<ChrisCuellar> Thanks jugglinmike !