I just bought a Zoom H2 Essential handy recorder that I absolutely don’t need.

Patrick Perdue

I just noticed that, with the BTA-1 adapter in the H2 Essential, it takes about 6 seconds longer to boot up. I've had the BTA-1 inside my H6 Essential since I got it, so now I'll have to see if it boots any quicker without it.

Patrick Perdue

Here is an annoying accessibility trend that I keep seeing lately.

The way that the Zoom Handy Control/Sync app exposes time recorded to Voiceover is by spelling everything out, I.E. ten minutes, twenty-seven seconds instead of 00:10:27, or 1 hour, fifty-five minutes, thirty-eight seconds instead of 01:55:38.

Since I am using Braille with my phone about 90% of the time these days, I thought it would be cool that I can now silently check the recording progress of my device, which is located somewhere not on my person, by using a Braille display connected to my phone.
Unfortunately, it's annoying, because, with everything spelled out like that, it takes up a ton of cells on the display for no good reason.

The Apple Watch does a variation on this when reporting seconds, by the way. So, it reads like 11:23 and 59 seconds instead of 11:23:59.

Why do people do this? Just give us numbers, and leave the interpretation up to whoever is reading it!

Of course, the Handy Control/sync app actually displays numeric format on the screen for the record counter, only Voiceover gets the expanded version. I verified this by taking a screenshot, then running OCR on it.

Time to send a note to Zoom about this one, I think. It isn't a show-stopper for most people, but it is also not necessary, and actively annoying in some cases. I have no idea if this affects language localization.

Simon Jaeger

@BorrisInABox I've been noticing this too, and even before I saw it in Braille I realized it would be horrible on Braille displays. I wish people would stop overthinking TTS and remember that Braille users exist. I don't understand this trend at all. I also have punctuation customized to report hyphens, so it's extremely obvious now. Definitely send a note to them. You could always ask if there's a reason they decided to do that.

James Scholes

@simon @BorrisInABox While I likewise wish people would stop overthinking TTS, the needs of speech and braille users are not equal, and hence there is a legitimate technical problem if the output of one is just being set up to mirror the other. There is always too much focus on speech in developer APIs, e.g. aria-label was present in the spec and widely supported long before aria-braillelabel.

to put it another way : if it's determined to be legitimately helpful for speech users to get a longer string, it should be technically possible and easy for developers to give braille users a shorter equivalent.

Simon Jaeger

@jscholes @BorrisInABox I see your point in theory, but I'm curious if you can think of examples of when a longer/different speech label might be useful. Most of the time it seems like the standard label could just be modified for conciseness.

Pitermach

@simon @jscholes @BorrisInABox Using the example of time, suppose an app is displaying relative time like 10 minutes ago, and visually shortening it to just M. It's up in the air whether TTS will say the M as "minutes" or "meters", I've seen it being interpreted wrong both ways. It's nice for Braille to have that shorter version while speech is also clear what is being meant. And I think there are definitely times when optimising labels for speech drags braille down where having separate labels would help. IE, in an email client you might want speech to say "unread, has attachments, important" etc where the braille versions could be shortened to something like unr, att, imp, leaving more space for the subject and other info with less scrolling. It's been a while since I used it seriously but iirc JAWS already does this in the email clients FS scripted

James Scholes

@pitermach Exactly this. I'd usually prefer the visible info to be understandable by as many audiences as possible, and for user experiences to match.

But at the same time, a lot of info is visually displayed with icons these days, and I despise unnecessary cognition. If your event details page says "November 5th, from 11 AM to 6 PM", I will be grateful that you've saved me the effort of working out what "five slash eleven eleven amm dash six pm" means. @simon @BorrisInABox

James Scholes

@pitermach Likewise, with the email example:

A lot of fundamental accessibility materials would tell you to give icons informative alt text if they mean something. But who wants to hear "graphic unread", down arrow, "graphic has attachment", down arrow, "graphic possible spam", down arrow, "graphic sender is not in your contact list", "down arrow, "link Earn $5,000 per week by doing nothing!"?

Much better to mark the icons as decorative, make the email element itself focusable, and give it a sensible name. Even more user-friendly if you then let me control which fields are included and in what order. @simon @BorrisInABox

Rebecca

@jscholes @pitermach @simon @BorrisInABox Sadly sighted testers don't think of braille when they should. Better yet have someone who uses braille test it. I recently learned that sighted testers use and think about screen readers differently than we do. They might see an issue that really isn't one.

Simon Jaeger

@silverleaf57 @jscholes @pitermach @BorrisInABox Yes. Throw a screen reader at a sighted developer who is on too much of a time crunch to read the manual enough to even figure out basic navigation, and suddenly that developer is throwing tab stops on static text and trying to turn the whole sight into a narrated experience instead of thinking about efficiency.