Screen reader issues

[LukasKalbertodt]

I tested the redesign with the standard Ubuntu screen reader and identified the following issues. I am not sure which ones are just fault of the Ubuntu thing, but here we go:

• After changing the step, it just says "open studio logo" or sth like that -> No idea how to fix :/
• maybe use <time> for the cut point timestamps? -> That's not the proper element for that, I think. Unsure how to best solve this.
• announce that recording statrted
• source select buttons could say "share display" instead of just "display"
• Video settings, when selecting an input should say "aspect ratio 4:3" and not just "4:3"
• Save locally buttons should mention which video they save
• focus stays in background when overlay box active
• how do screen reader users read body text (i.e. no link, button, ...)?

[owi92]

I've gone over these one by one and fixed the easier ones, and have some notes regarding the others.

After changing the step, it just says "open studio logo" or sth like that -> No idea how to fix :/

This isn't happening with VoiceOver on macOs, tested all major browsers. When changing a step, instead of the alt logo text being read like you experienced, VoiceOver reads the step's heading, i.e. "Camera selected" and so on. Can't test this with other screen readers, but I'd guess what you described is only happening with the Ubuntu screen reader.

maybe use for the cut point timestamps? -> That's not the proper element for that, I think. Unsure how to best solve this.

Yeah also stumped by this. According to the mdn specs this should be possible with the <time> element and the right formatting, and I really tried but couldn't get it to work unfortunatly. Maybe we need to convert the string to something human readable, but that also seems kinda overkill?

announce that recording started

I addressed this by adding aria-live: polite to the recording button. This means it won't say "recording started/stopped" but instead read the updated description of the button, i.e. pressing "record" then reads/prompts the user to "pause recording". I think this is a sensible solution, but if you'd really prefer a proper announcement, I'm sure that won't be too hard to do either.

source select buttons could say "share display" instead of just "display"

Added this in my PR.

Video settings, when selecting an input should say "aspect ratio 4:3" and not just "4:3"

This was the other thing I spent some more time on. Just doing what you propose wouldn't be hard but I also think this wouldn't be enough. For one, I think it would be better and more accessible if these radio buttons act like regular radio buttons as outlined in the mdn specs, meaning

• they should belong to a radio group, so that their label (aspect ratio/quality) is read once when entering the group
• they should be navigatable and selectable using the arrow keys instead of the tab key (this is the default behaviour and I suspect it's what screen reader users would expect from this)
• the modal should probably not close upon selecting a value, but have a dedicated "apply" button instead so a user can choose both aspect ratio and quality without having to reopen the dialog
  I haven't done this yet as I would like to hear your opinion (and maybe others) on this first. We could also move this to a seperate issue.

Save locally buttons should mention which video they save

Added in my PR.

focus stays in background when overlay box active

Not sure what you mean by that. Should the boxes (or their title) be autofocused when opened, and should focus be trapped in these?
I think that is at least partially the case, as while this isn't autofocused, it does get focused by pressing tab once, and it also isn't possible to focus anything else on the page itself. Focus isn't exactly trapped since users can still tab to the browsers address bar etc.
Nevermind. Just realized that in chrome and safari tabbing is somehow restricted to the browser toolbar. What I described above is just the behaviour in firefox. Well I guess then it should really be autofocused or something similar.

how do screen reader users read body text (i.e. no link, button, ...)?

When opening an overlay box with text like the shortcuts or infobox, I can use arrow left and arrow right to navigate through the text elements. In VoiceOver, I need to specifically enable that behaviour (here it's called "fast navigation"). I think JAWS and NVDA should have a similar function, and I would expect the ubuntu thing (is that orca?) should as well.

[lkiesow]

After changing the step, it just says "open studio logo" or sth like that -> No idea how to fix :/

This isn't happening with VoiceOver on macOs, tested all major browsers. When changing a step, instead of the alt logo text being read like you experienced, VoiceOver reads the step's heading, i.e. "Camera selected" and so on. Can't test this with other screen readers, but I'd guess what you described is only happening with the Ubuntu screen reader.

That should have happened because the logo was a link. It is no longer. That's probably why this has changed and is no longer an issue.

[LukasKalbertodt]

Thanks for your PR and comment!

After changing the step, it just says "open studio logo" or sth like that -> No idea how to fix :/

This isn't happening with VoiceOver on macOs, tested all major browsers. When changing a step, instead of the alt logo text being read like you experienced, VoiceOver reads the step's heading, i.e. "Camera selected" and so on. Can't test this with other screen readers, but I'd guess what you described is only happening with the Ubuntu screen reader.

That should have happened because the logo was a link. It is no longer. That's probably why this has changed and is no longer an issue.

This is still happening with Ubuntu screen reader. I just tested the PR and master. After saying "Opencast Studio Logo" it also reads the <h1>, which is good. But yeah, blaming Ubuntu's implementation here.

I addressed this by adding aria-live: polite to the recording button. [...]

This unfortunately doesn't work in Ubuntu's screen reader. But again, I don't expect that implementation to be super good anyway. And yes it's Orca or something, but I assume the OS still has to do some work to glue everything together, so I think there are some Ubuntu-specific bits we can blame here.

focus stays in background when overlay box active

Not sure what you mean by that.

I meant that when the box opens, elements in the background are selected and one tabs through those. I.e. yes, focus should be trapped inside the popup. But retesting this right now, this seems to be fixed.

how do screen reader users read body text (i.e. no link, button, ...)?

When opening an overlay box with text like the shortcuts or infobox, I can use arrow left and arrow right to navigate through the text elements.

Ah thanks, I didn't know that. Also work on Ubuntu.