I've just pushed a bunch of #accessibility changes for screen readers to the main branch of FediThready. ( It makes long texts into post sized chunks)
I've run through it with #VoiceOver and it seems ok. HOWEVER it all feels like it's "usable" instead of "good".
If there's a #a11y geek out there who uses screen readers regularly I would REALLY appreciate some suggestions on how to make this actually feel good for folks who rely on screen readers.
I've been playing around with keyboard scrolling of overflow regions, and I was interested to note how Firefox's native behavior doesn't expose any additional semantics -- i.e., it doesn't apply a role or accessible name when the scrolling region becomes focusable.
And I think that's the right thing to do -- that our standard workaround of including role="region" and aria-label or aria-labelledby (along with tabindex="0") creates unnecessary verbosity.
Because navigating an element with the virtual cursor isn't affected by scrolling. Virtual navigation already allows for keyboard access to the overflow, and it makes no difference to navigation or spoken output.
Tab navigation is affected of course, because it's the difference between whether an element creates a Tab stop or not, but this also doesn't require a label, I don't think, because Tabbing to such an element causes the first line to be read anyway.
I've created a demo script on that basis, which doesn't add a role or label, it simply adds or removes tabindex based on whether the region actually has overflowing content.
It's triggered by a ResizeObserver so it continually updates in response to anything that changes the element's size (and you can test this by resizing the window, increasing zoom or font-size).
Lol, folks. Listen to your article before you post it. Doesn't matter what voice. You'll catch things like this from macrumors.com. In the app's settings (accessed via ChatPGT ➝ Settings… in the menu bar when the app's main window ...
It's always so frustrating when all the web accessibility content only talks about text heavy websites and forms. Like yes, I get it, I should have alt text on images. But there's so little information about how to build accessible web apps. What do I do if 80% of my page is a WebGL canvas and the other 20% is all buttons/sliders? How do I structure this if there is basically no "regular text" on the entire page?
I was going to leave Feedback® about making SwiftUI .accessibilityLabel work with SSML, but I found out that we could cook it ourselves #Accessibility#SwiftUI
BeMyEyes Privacy Policy 1/2: We record and store video streams and other images to enforce our Terms of Service, to promote and preserve safety, and to improve our Services and create new Services. We may provide recorded video streams or images to other organizations that are performing research or working to develop products and services that may assist blind and low-vision people or other members of the general public.
Begging creators and developers to use this tool to see if there are harmful flashing effects. I’m sick and tired of people slapping a “strobing effects” warning up front and calling it a day. #epilepsy#accessibility https://trace.umd.edu/peat/
The most egregious example of this is video essay editors using literally flashy effects that make their videos impossible to watch. You chose to use those filters. Stop it.
Tori Lacey, 26, chronicled the troubling incident on her #TikTok & #Instagram pages, where she usually posts content about her #travel exploits as a person who uses a #wheelchair.
I am once again a bronze supporter of Inclusive Design 24.
I want to see all of you presenting cool stuff (and making me look good as a result), but you won’t get that chance if you don’t submit before 7 June. https://inclusivedesign24.org/2024/
Prior years are up there if you want to see the range of talks that have been accepted in the past.