Designed for distraction, not for usability. What does the mysterious number in the title mean?
The overcharged interactivity on the web interface does not follow good design principles and technical best practices, so they couldn’t be accessible on their own.
They attached a11y as an afterthought by re-inventing many wheels, instead of relying on common usage paradigms and habits.
Such companies think they’re so important that blind persons want to learn their keyboard shortcuts and idiosyncrasies.
As a result, they had to integrate many technical instructions with awful german translations: „Sie befinden sich in der Nachrichtenüberlagerung. Drücken Sie zum Verkleinern die Eingabetaste.“
If such hints come directly from assistive technology, blind users can choose their preferred verbosity.
Screenreader navigation on web pages is quick and reliable.
The UI of Firefox itself is sometimes slow and unreliable due to its strange mixture of web-based and Mozilla UI toolkit, especially preferences and dev tools.
The a11y feature is based on detecting a cookie in the browser via XSS, which is extremely unreliable in real-world scenarios with decent privacy settings enabled (ecological validity)
Old web frontend with many a11y issues, but no fancy HTML tag abuse which could break a11y completely. Links are links, inputs are inputs, no surprises.
There’s no single heading element, e.g., for thread titles or page titles. You have to deduce from the content: „O, this might be the title.“
Regions like navigation and main content are not clearly separated. This can be accomplished by using either HTML5 semantic tags or aria landmarks.
Comments in a thread are not identifyable as self-contained entities (article tag), just paragraphs intertweened with upvote buttons and metadata. You have to remember whether these controls are above or below a comment to find the correct ones.
Lets blind musicians explore and write scores, has rudimentary braille music output.
The most accessible QT app I know, but heavily relies on their own navigation concepts and hotkeys instead of the OS-native ones.
Braille music is more abstract than traditional music notation. Knowing the visual concepts of music notation helps blind users to understand some concepts in MuseScore.
Feels like a Klickibunti site from the early 2000s, not like a modern web app with proper UI controls. High degree of HTML tag abuse: Many links actually should be buttons or toggles, other clickable elements are just span elements with click handlers.
No navigational landmarks to move to available sections, clusterfuck.
Screenreader cannot read text in the chat input.
Dialogs break when too many ones are open, improper app state management.
Delightful syntax, helped me to design a card game as a blind person.
How to test an app?
A modern OS comes with a screen reader installed. Just turn it on and try to use your app or website with keyboard commands. If you need your mouse, your app is probably broken.