brainwane: My smiling face, including a small gold bindi (Default)
[personal profile] brainwane
Whisper, from OpenAI, is an open source speech recognition tool that also does translation. You can try it right now at https://replicate.com/openai/whisper or install it on your own computer to run privately. You provide an audio file, and it emits a text transcript as well as .srt and .vtt subtitle files.

This is a really useful (and free!) tool. I have started using it regularly to make transcripts and captions/subtitles, and I just wrote a blog post to share how, and why -- plus my reflections on the ethics of using it and similar tools trained using machine learning.

Note that it works on existing files, but does not work for live-transcribing an event as it's happening.

jesse_the_k: Baby wearing black glasses bigger than head (eyeglasses baby)
[personal profile] jesse_the_k

It’s a cool concept, hides clutter in your room. Also creates barriers.

Zoom virtual backgrounds combine you in the foreground with something nifty in the background. (Think the weather reporter on TV in front of a big US map.) In the past week I've seen the prow of a ship, inside of Tardis, comets, the Hamilton stage and more. Zoom itself says This feature works best with a green screen and uniform lighting, to allow Zoom to detect the difference between you and your background. -- which is not equipment most people have at home!

The Zoom software uses clever algorithms to isolate your outline from what your camera captures. But these algorithms often fail for delicate edges, like hair or hands. Outcome: every movement captured on camera includes Zoom struggling to adjust the edges, which can result in your head and hands sparkling, flashing, or disappearing altogether.

It’s distracting and unpleasant for me when even one user has the virtual background. For some of us with migraine, vestibular issues, brain injury or epilepsy it can be a complete barrier.

Even if the software works perfectly, some of the available backgrounds include so much detail that it overwhelms your image. I can’t read your facial expression, much less your lips. This results in no benefit to using video at all.

Do you have issues with this aspect of Zoom? Are there benefits to the backgrounds that I'm missing?

alexseanchai: Katsuki Yuuri wearing a blue jacket and his glasses and holding a poodle, in front of the asexual pride flag with a rainbow heart inset. (Default)
[personal profile] alexseanchai
So one of my AO3 readers is a screenreader user, and she tells me her laptop does not play nice with emoji. (Her phone does, but that's not the point.) One of my Dreamwidth readers tells me that of these six emoji, 😸🥐🥗🚰🤒🦗, on her Windows 7 computer she sees two; the other four show up as the "Windows cannot identify this character" box. And at the size the emoji are displaying for me, I can't visually identify any of them. I know what five of them are without pasting them into Google, but that's because I know what I was doing last night when I was working on this fic; before googling, I cannot remember which cat face I used.

[Left to right: grinning cat with smiling eyes, croissant, green salad, potable water, face with thermometer, cricket. If I did not already know that was a cricket, I would wonder why there is an emoji of a queasy chicken.]

AO3 Work Skins/Tutorials series has, under the iOS text mockups one, a workaround for AO3 being uncooperative with emojis. Vintage 2016. As of November 2018, AO3 and emojis get along fine. HTML and I also get along fine, provided I can get to w3schools; CSS and I do not, and what we're relying on in those tutorials (and also in Repository) to get the visual effect of the iOS text messaging or whatever, without sacrificing accessibility for readers of downloaded fic copies et cetera, is AO3 work skins with CSS. Now, this workaround has image descriptions in for emoji (using the title attribute), so presumably there is a way to make the emoji accessible for all concerned, though the workaround is no longer necessary in order to make the emoji appear at all without eating everything later in the fic.

(I absolutely did not notice in October 2018 that only the first scene of the last part of something I posted that August was up on AO3. Nope. Certainly not.)

...So how do I do this?

(I'm linking this post in this comment thread, so anything we work out here is also there for the benefit of any other people turning to that AO3 tutorial for emoji help. So you know.)

ETA: Having been reminded by an article on image alt text best practices that the title attribute is approximately useless to users of either screenreaders or touchscreens, it follows that the above-mentioned workaround for emoji on pre–November 2018 AO3 was never useful for screenreader users at all—or touchscreen users, whom it hadn't occurred to me to worry about. (They type wryly, on their tablet's touchscreen keyboard.) So I'm suddenly a lot less sure my question has an answer. Also, using a span tag with a title attribute to handle transliteration and translation of hanzi, like I'm doing here with 敏嵐, clearly isn't going to work either! Which expands the scope of my original question somewhat... (I'm copying that HTML into a comment below.)

With the emoji, the workaround [personal profile] stellar_dust and [personal profile] sylvaine suggest of images with alt text should indeed work. I'm still looking for a way to treat emoji as, essentially, text, because they're Unicode and that makes them essentially text, right? The hanzi, though, those are text, there is no question of it. I seriously do not want to screenshot the hanzi in order to embed an image with alt text if there is any way to avoid that while keeping the transliteration and translation attached to these bits of text!

(...the Mandarin transliteration, anyway, as found on Wiktionary. But this isn't where to ask about where to find the Wenzhounese transliterations my fic is more in need of...)
jesse_the_k: text: Be kinder than need be: everyone is fighting some kind of battle (Default)
[personal profile] jesse_the_k
It IS exciting to see kids interested in engineering, and I know [personal profile] selkiechick posted with the best intention.

However, that announcement pushed a whole row of my Assistive Technology Geek buttons, and I gotta rant. I'll can use the "BRAIGO" to illustrate why I get so hot under the collar. (My cred: I've hung out with people who use assistive technology since 1982; I designed and sold braille translation software and embossers in the late eighties; and I've personally depended on assistive technology since 1991.) Based on thirty year's close attention to the development/PR/funding/purchasing/abandonment cycle for assistive technology, here's my take on the BRAIGO announcement.

DESIGNERS GET COOKIES FOR PROTOTYPES, NOT AFFORDABLE PRODUCTS )

DEVELOPMENT WITHOUT EXPERT ENDUSERS IS POINTLESS  ) That's why the BRAIGO can't create useful braille.

PR BECOMES DISINFORMATION ) A $350 embosser would be an amazing thing. Hundreds of well-intentioned editors and readers are willing to take the inventor's word for it. But this device is not a embosser.

EXPERTS ARE AVAILABLE on REQUEST! ) We live in a press release culture: what the company wants to say is what we hear. Or in this case, what a 12 year old (who mentions absolutely no contact with braille users) says gets broadcast.


FAST FACTS RE EMBOSSERS & BRAILLE )

Start from the first dot at the RNIB's Learning Braille site or pick an excellent start for adults at the Achayra firm in India. Teach more at the National Federation of the Blind's Braille is Beautiful resource for kids.

tl;dr Just because assistive technologies are tools for people with disabilities doesn't mean we must accept only good intentions. We want the best engineers working on our designs, the best marketers making them affordable, and the best politicians making them subsidized.
elf: Quote: She is too fond of books, and it has turned her brain (Fond of Books)
[personal profile] elf
Only indirectly related to fandom (I know plenty of fen who've switched to ereaders for much of their reading), but strongly related to accessibility: Amazon, Kobo and Sony are requesting that the FCC exempt dedicated e-readers (PDF) from the requirement to be accessible.

"The public interest would be served by granting this petition because the theoretical ACS ability of e-readers is irrelevant to how the overwhelming majority of users actually use the devices," it says, as if any accessible features were granted because those were how the majority used them.

It goes on to say "E-readers simply are not designed, built, or marketed for ACS, and the public understands the distinction between e-readers and general-purpose tablets." I... have my doubts about that, especially since e-reader manufacturers work really hard to imply that there's no difference, just BW e-readers and color e-readers.

Most of the functions that would require ACS don't exist on many ereaders; I don't agree that means the rest of them shouldn't require it. I suspect this is a ploy to get Kindles into schools without having to be accessible to students with disabilities. Possibly, though, it's exactly what it says it is: an attempt to allow browsers and social media software on limited-use devices without holding them to the same standards as phones and tablets.

ETA1: changed link to the FCC page with embedded PDF.

ETA2: There's a request for comments that last through THIS MONTH. Comments Due: September 3, 2013

"Comments and oppositions are due within 30 days from the date of this Public Notice. Reply comments are due within 10 days after the time for filing comments and oppositions has expired."
holyoutlaw: (Default)
[personal profile] holyoutlaw
Does anyone know of any tablet-based apps or practices to help someone recovering from a stroke with communication issues? "They" probably want him to do a lot of handwriting, because he was an artist, but a tablet might be helpful for regular things.

Thanks in advance!
runpunkrun: Pride flag based on Gilbert Baker's 1978 rainbow flag with hot pink, red, orange, yellow, sage, turquoise, blue, and purple stripes. (Default)
[personal profile] runpunkrun
Hi folks, I need some help with making the author commentaries I've written compatible with screen readers. Author commentaries are story texts that have paragraphs of commentary inserted into them. In the two I've written, the only way to differentiate between story and commentary is visually and I'd like to fix that. Here's how my commentary for "Meanwhile, Back in Metropolis" is currently formatted using css. Paragraphs of commentary are set off from the story by a blue background, which I'm sure a screen reader couldn't care less about. I could easily create a div class "commentary" for those sections, but I don't know if screen readers typically announce that sort of information.

So my question is: How can I set apart the commentary sections in a satisfactory way for fans with screen readers?

Googling, I found Designing for Screen Reader Compatibility, which describes how to hide content visually while still making it available to screen readers. I could add "Commentary:" in hidden text in front of every section of commentary. But would it have to be in front of every paragraph, or is once a div enough? Would it be helpful to have a hidden "end commentary" text as well?

I only have a basic understanding of how screen readers work, so if there's a simple solution that I've overlooked, it's probably because I didn't realize it was an option. I'd appreciate your input and any suggestions you might have. I know that not everyone uses their screen reader in the same way.

Thank you for your help.

May 2025

S M T W T F S
    123
45678910
111213141516 17
18192021222324
25262728293031

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags