[HN Gopher] Vojtux - Unofficial Linux Distribution Aimed at Visu...
       ___________________________________________________________________
        
       Vojtux - Unofficial Linux Distribution Aimed at Visually Impaired
       Users
        
       Author : TheWiggles
       Score  : 115 points
       Date   : 2026-01-07 11:43 UTC (4 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | jmward01 wrote:
       | I'm glad to see things like this get built. I hate to admit it
       | but I rarely consider impaired usecases when building things. I
       | wonder how technology is changing this usecase lately both on the
       | user end and the design end. (I know, AI) I imagine an LLM could
       | help discover inadequate UI and build alternative workflows into
       | products more easily.
        
         | shakna wrote:
         | Whispir is a much better TTS than almost anything else.
         | However, when it gets it wrong, oh boy does it get it wrong.
         | 
         | For everything else? Not really. JS thrashing the DOM is as
         | much a pain as ever. Using ico files instead of either emoji
         | or... Text... Makes UIs painful and inconsistent.
         | 
         | Everyone using Electron and its broken [0] accessibility,
         | including core Windows features...
         | 
         | These aren't things that can be reasoned away with an LLM. An
         | interface is not just text - its a reasoned nodegraph. And when
         | I'm blind (comes and goes), I need the nodegraph. Not an image
         | of the screen reinterpreted.
         | 
         | [0] https://github.com/electron/electron/issues/45856
        
           | graemep wrote:
           | I find it very hard to know what to do to follow best
           | practice. For example the biggest UK charity for blind people
           | make social media posts about the importance of text
           | descriptions and alt tags that break what I thought was good
           | practice (they duplicate text in post and alt tag) and they
           | seem to encourage this.
        
             | shakna wrote:
             | I don't recall where, but I've heard that before in the
             | past. Perhaps in the kind of slop that makes the rounds on
             | LinkedIn.
             | 
             | There is sort of a good reason for it, in the past. Before
             | the overhaul, Microsoft Speech used to skip Facebook posts,
             | and read the alt text instead. It is now, however, more
             | sane. Facebook was pretty darn bad at accessibility in its
             | early days. A lot of intermingled broken spans for text,
             | causing stuttering and other issues.
             | 
             | However, today, most reading systems prefer the "title"
             | attribute, to the "alt" one. If title exists, it'll read
             | that and skip alt. Some always skip alt, regardless of it
             | exists or not.
             | 
             | Figure and figcaption are about the only way to get good
             | and consistent behaviour, but you don't really control how
             | those happen on most social media platforms. You throw
             | everything you can at the wall, and see what happens. And
             | it might change tomorrow.
             | 
             | Today, I'd say the above is bad advice. An image
             | description is a good practice. Repeating yourself, isn't.
        
               | zersiax wrote:
               | Wait the title attribute?
               | 
               | 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
        
               | shakna wrote:
               | 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.
               | 
               | [0] https://github.com/FreedomScientific/standards-
               | support/issue...
        
               | zersiax wrote:
               | 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.
        
               | shakna wrote:
               | 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.
               | 
               | [0] https://html.spec.whatwg.org/multipage/dom.html#the-
               | title-at...
               | 
               | > 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.
               | 
               | [1] https://w3c.github.io/aria/#aria-label
               | 
               | [2] NVDA bug confirming they use it:
               | https://github.com/nvaccess/nvda/issues/7841
               | 
               | [3] Sorry for the numbers everywhere. I've got a footnote
               | macro set for the way most HNers use this.
        
               | graemep wrote:
               | Thank you, that is quite informative.
               | 
               | The specific posts I see are from the Royal National
               | Institute of Blind People who really ought to know.
               | 
               | What they do is add the image description at the end of
               | each text post, even thought this matches the alt text.
               | 
               | This is the one about using alt text: https://www.faceboo
               | k.com/rnibuk/posts/pfbid037RmtoSxfAJX82G4...
               | 
               | They do now have a comment on that one that explains
               | their reasoning (I did not see it until just now).
        
           | jmward01 wrote:
           | I imagine this is where LLMs could really help actually. LLMs
           | are natively surfing the web now so I suspect LLM
           | descriptions of sites or even having them re-render a site in
           | a more usable way is becoming much more possible.
        
             | shakna wrote:
             | I don't need the text of the page. Thats easy, and I
             | already have it.
             | 
             | But information has a hierarchy, usually visual, and that
             | hierarchy needs to be reflected. LLMs are famously bad at
             | structure, especially any tree with significant depth. RAG
             | is not enough - hallucinations become common at depth.
             | 
             | My response now, to you, is in a semi-structured node
             | graph. I know a reply has happened, because of the dangling
             | children. I know who made it, and what they said, by cell
             | attributes in the spans, surrounding it.
             | 
             | Don't worry - AI is being shoved down accessibility's
             | throat, like everywhere else. FSCompanion for JAWS, NVDA
             | has an OpenAI plugin, and VoiceOver has it builtin.
             | 
             | Why do I hate it? Because when it _doesn't work_, you can't
             | tell. You don't know if it is hallucinating data, and
             | cannot verify the response. If it is the mode of
             | communication, it is all you have, making every failure a
             | catastrophic failure.
        
               | jmward01 wrote:
               | Thanks for helping me, and hopefully others, understand
               | the challenges more!
        
             | UqWBcuFx6NV4r wrote:
             | Visually impaired people are more than willing to tell
             | everyone what they need as far as accessible UIs, myself
             | included. Barely anyone listens. Let's not let LLMs be the
             | next thing that people that don't understand the actual
             | problem try shoving in as a solution.
             | 
             | Wheelchair users / people with mobility impairments
             | rightfully scoff at the myriad "concepts" you see now and
             | again of mech suits, wheelchairs that can climb stairs,
             | etc. "Just give us a ramp! This is a solved problem. Your
             | alternative is just sci-fi fetishism!" Still, it keeps
             | happening. LLMs are increasingly becoming the same thing
             | for people with visual impairments.
        
         | zersiax wrote:
         | '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
        
       | cl3misch wrote:
       | Are there "official" Linux distributions?
        
         | klez wrote:
         | Maybe "unofficial Fedora version" would have been more
         | deserving of the "unofficial" specification.
        
         | bandrami wrote:
         | GUIX is the official GNU Linux Distribution
        
           | SahAssar wrote:
           | That is not an answer to the question. There are no "official
           | linux distros".
        
           | bmacho wrote:
           | Does GNU know about that?
           | 
           | https://www.gnu.org/distros/distros.html
        
       | mngnt wrote:
       | Here's an interview (in Czech) with Vojta, the main (only)
       | developer. There might be follow up articles discussing specific
       | issues he's facing as user and as a developer.
       | 
       | https://www.root.cz/clanky/pristupnost-se-musi-stat-obcanem-...
        
       | zersiax wrote:
       | 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.
        
         | shaky-carrousel wrote:
         | 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.
        
           | serial_dev wrote:
           | 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.
        
           | nicoburns wrote:
           | > adding accessibility is boring
           | 
           | 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.
        
         | RobMurray wrote:
         | The readme addresses this problem comprehensively. "The
         | ultimate vision of Vojtux is "NO VOJTUX NEEDED!" because Fedora
         | will be fully accessible."
         | 
         | It's not really a distro in the usual sense, more a minimal
         | customisation of Fedora.
        
         | a-dub wrote:
         | seems like the real places to make durable changes would be in
         | the desktop environment software packages (kde, gnome, etc)?
         | 
         | although it also seems useful to figure out which third party
         | packages and default settings make sense.
        
       | kachapopopow wrote:
       | I was looking at this wondering where are the previews, images,
       | etc... yep, right, this is for people who can't see properly.
       | 
       | Was pretty eye opening.
        
       ___________________________________________________________________
       (page generated 2026-01-11 23:01 UTC)