'Honestly this is a people problem more than a tech problem. We have the tech. We're just not using it.
I'd say LLMs COULD make it easier to implement accessibility, it also couldn't, always a coinflip with those, but I'd say LLMs actually succeeding is probably unlikely given how much shitty code is probably in its training data :P
The tricky thing with these "unofficial" distros is that they are generally maintained by either a single individual or a small group of people.
This is true for many accessibility projects actually (game mods, third-party UIs for inaccessible services/platforms, etc.).
These are generally really meant as short-term patches while the problem gets fixed, except ... the problem often doesn't get fixed because the platforms in question figure it's been solved now and they don't need to care about it anymore.
Accessibility really only works when it's an ongoing, first-class process within an app/platform's design, and we can absolutely do that; the standards and guidelines have existed for decades. People working in cybersecurity, localization, general UX should recognize this song and dance, which is amusing because a lot of the tools of those trades have atrocious accessibility and require all sorts of workarounds, ask me how I know.
People just ... aren't including it in this way, which means people like myself (screen reader user and accessibility professional) essentially have to keep reminding people that we exist and that it's kinda shitty to keep forgetting about that fact or to decide the least amount of effort possible (LLM, unpaid volunteer, send in a PR LMAO) is enough to cater to people who have very real, very annoying and very constant UX issues we either crash into or crash through on literally an hourly basis.
It's because adding new shiny features is fun and adding accessibility is boring, and most people in the free software world are there to have fun. That's also why bugs are always forgotten while people keep piling new features.
I also think it's partly because adding accessibile interfaces is hard.
If you are not visually impaired then designing then when designing a visual interface for an application you are more-or-less designing for yourself. You know how to use visual interfaces, so it is relatively easy for you to evaluate whether you've done a good job.
Most people do not know how to use a screenreader, so if you're designing for a screenreader then it's going to be much harder for you to test the interface and evaluate whether it's actually usable by it's target audience.
I'd also love to see more educational resources on this topic. Not just "use this attribute/role for this use case", but "this is how using a screenreader works. This is an example of a good workflow . this is an example of bad workflow". There's tons of material out there for visual design, but I haven't come accross nearly so much for other interfaces.
It’s not a free and open source issue, it’s a general issue in product development.
Whereas in free software, people develop apps to have fun, in business product development, teams always try to ship a feature that is the highest leverage, and making the app work well with screen readers is usually not the highest leverage item, unfortunately.
What are you basing that on? Screen readers tend to not pick those up at least on interactive elements by default, you need to do a bit of "wiggling" to get those to be announced.
Disclaimer: screen reader user
JAWS user, here. It will read both aria-label and title, on a button, which is an interactive element. [0]
It does depend on the verbosity, if you dial that down, you'll probably lose the title element. But for images, which is what I was mentioning, it should pretty much always be read out.
I am ... relatively sure JAWS reads out title attributes of images because people kept erroneously sticking important info there decades ago, I wouldn't say that's a generally accepted recommendation. Not entirely sure what NVDA would do with an image that has only a title but no alt set.
ARIA and the web group define title to be used. [0][1] It's just that many agents just don't use it correctly. JAWS and NVDA do. Microsoft Speech used to ignore it, but I think they fixed that around Windows 11 release. I'm not sure about VoiceOver. Most braille readers I've used... Well, you'll be lucky if they read anything correctly.
With the three big ones, JAWS, NVDA and Speech using it correctly, I'm pretty happy guiding people to use it today.
> The title attribute represents advisory information for the element, such as would be appropriate for a tooltip. On a link, this could be the title or a description of the target resource; on an image, it could be the image credit or a description of the image; on a paragraph, it could be a footnote or commentary on the text; on a citation, it could be further information about the source; on interactive content, it could be a label for, or instructions for, use of the element; and so forth. The value is text.
> Most host languages provide an attribute that could be used to name the element (e.g., the title attribute in HTML), yet this could present a browser tooltip. In the cases where DOM content or a tooltip is undesirable, authors MAY set the accessible name of the element using aria-label, if the element does not prohibit use of the attribute.
From the article I'd assume this wouldn't work in any way for mobile given no hover, not for screen reader users because a website often has no idea where a screen reader's cursor is, and potentially not for keyboard users (haven't checked if keyboard focus triggers this prefetch/prerender or literally just mouse hover), so ... limited applicability, I'd say.
Part of the design of the feature is that the website doesn't have to specify "on hover" or "on focus", but instead they can just write "eagerness: moderate" (or "conservative", or "eager") and let the browser decide what the exact triggers are. If it turns out that keyboard focus is a useful predictor of whether a link is likely to be clicked, then browsers can add that as a trigger at one of the indicator levels, and websites will automatically get the new behaviour "for free".
Currently, "eagerness: conservative" activates on mouse/pointer down (as opposed to mouse/pointer up, which is when navigation normally happens), which will work for mobile devices as well. And "eagerness: moderate" includes the more conservative triggers, which means that even on devices with no hover functionality, prerendering can still kick in slightly before the navigation occurs.
maybe its the fact that its really easy adding something like this, and this (I think) or something which basically acomplishes the same thing (but in a better way?) are used by some major meta frameworks like nextJS etc.
I guess it has limited applicability but maybe its the small little gains that add victories. I really may be going on in a tangent but I always used to think that hardware is boring / there aren't too many optimizations its all transistors with and,or,not
but then.. I read about all the crazy stuff like L1 cache and the marvel machinery that is known as computers.
It blew my mind into shredders.
Compilers are some madman's work too, the amount of optimization is just bonkers just for tiny performances but those tiny performance boosts in the whole stack makes everything run so fast. Its so cool.
This is a really cool concept :) Generally in language learning it's a good idea to try to "think" in the language as much as you can so you get creative about how to phrase something with the words you do have, but if that fails, particularly when you're just starting out this is a great motivational aid and conversation starter if nothing else :)
I would definitely recommend integrating with an established translator like DeepL as well as a kind of second correction as AI does get things wrong and having the two versions can help compare what may have gone wrong, you can probably keep your autodetecting language bit as well as I am pretty sure DeepL supports language identification and if not, I know Google does.
Good luck with learning Danish, I tried my hand at it a few years back but have switched to Finnish as of early this year
I'm sure it's fast, but is it accessible? Am I as a screen reader user going to get fired if the company I work at decides one day to have all of their devs use this? And if not, any plans to make it so?
Might sound a little brusque but this really is the stakes we're playing with these days.
I love this idea, it would actually solve a lot of accessibility issues within coding courses for the fully blind. Unfortunately right now the scrimba interface appears to need some help where that is concerned. WOuld love to discuss more if you're interested? @somebee
You're not wrong but I think there is absolutely a case to be made for these kinds of restructurings as well. For one, giving you the restructured version exposes you to different ways of stating the same content, it might make reading longform content (without falling back to the original source material too often) more fluid, and more situationally, this kind of simplification and restructuring actually happens really often in subtitling, where character count is more leading than the lip movements a dub is based on. e.g. you'll hear one thing, but the sub is that same content often radically redone :)
I'll check that out :) I'd be curious how well this would work without being able to see the video you're messing with (fully blind myself). Will give that a whirl.
I'd say LLMs COULD make it easier to implement accessibility, it also couldn't, always a coinflip with those, but I'd say LLMs actually succeeding is probably unlikely given how much shitty code is probably in its training data :P