> Accessibility in both Notion and Confluence is absolutely abysmal.

And that's just for people with typical hands and eyes.

Imagine of what it's like for people with disabilities.

Piggybacking to ask: I'd love to pay like a $100 to a person with disabilities to use my website for a couple of hours and shit on the experience. Has anyone ever done this? Is there a service you've used and have been happy with?

My exerience with automated tools has been less than stellar. Oh, an image has an alt tag? Congrats, it's accessible, even if that alt tag literally just says "alt tag". I also don't think "simply turn on accessibility features yourself" is a proper solution. It feels like there's a massive difference between me using such tools for the the purpose of testing one website and someone actually relying on such tools.

This feels like it should be a more concrete service, with a focus on actually interacting with the testers. Maybe this exists already, but my limited experiences have been using "accessibility certification" services where you submit a site, and days or weeks later get back a huge list of stuff to "fix" without any real guidance or ability to even check "is this what you meant?" before resubmitting and waiting for days/weeks again. It's the opposite of 'fast feedback' and 'talking to end users' - slow feedback mediated through a service preventing any interaction with the actual testers.

Generally what you want is to have people like this embedded within the team/the company itself for this reason. When I do an audit, or when I stream on Twitch about a product/website/whatever I aalways make sure I remain available for questions/followups, but accessibility isn't a checkbox to check, it's a standard you maintain and that means experts need to be there to help you maintain that standard.

Not everyone can afford to have extra team members doing that. Some of us are working with skeletal teams to begin with, but would still like ways of validating/reviewing a11y concerns with real people, not just scripts and automated tools. And yes, on an ongoing basis, not just a one-time thing.

Oh absolutely. In an ideal world, we see a lot of disabled folk with a bunch of applicable knowledge be hired to do this for companies. The reality is that a lot of people who have the knowledge are actually unemployed, the teams who want to hire them don't have the budget for it, and the large corporations that should know better don't think the effect on their initial bottom line is worth not wilfully excluding a whole bunch of people. like, I have literally seen companies just decide that risking the 20k settlement for an ADA lawsuit is cheaper than fixing all the accessibility issues they managed to include, at which point the business case of making money and the non-business case of not being dicks to a potential huge amount of people clash. Usually, business wins.

I'd say for smaller teams it is doubly important to think about this topic early to minimize the overhead of having to fix a whole bunch of bad moves you figure out you've made when someone complains months or even years after you've made them. As for doing this now and again, I think some of the QA firms like APplause and such do offer accessibility testing services and such now, and there's social media like HN, Reddit, Mastodon or, if one must, X, where people can be found who'll be happy to do this provided they can be fairly compensated. Not exactly structural or centraalized but there you have it :)

If you use HTML5 and use the alt settings, have simple tables and use a friendly color palette your 90% better than most on accessibility.

That is pretty much my dayjob :P Although I'm also a developer myself so can argue from both the blind person's view of "This button doesn't tell my screen reader what it's meant to accomplish", as well as the developer's point of view of " You simply forgot to add an accessible label, don't you dare tell me you don't have capacity to fix something that'd take 10 seconds to fix". ;)

The argument is we don't have capacity to learn what needs to be fixed, and it's the unfortunate truth that figuring out other things instead generally has better ROI :-(

That is the sad part, yeah. You'd think with the ADA existing since the early 90s things like coding bootcamps and CS college degrees would spend more time on this but they really, really don't. I taught that class myself to my peers when I was in college which is depressingly bad, but I'm at least glad I was able to pass that, what we now call, native experience along, i guess. That's really why I stream now, as well.

Concrete "this to that" examples are worth their weight in gold[1] for how to make simple steps forward in accessibility, along with some sort of a demonstration of how it changes the experience.

I'm sitting on a codebase with ~20 HTML ARIA warnings from SvelteKit's lint and frankly don't expect to get to fix them any time soon. I'd like to, but there's always something else to put the effort into. And that's when the framework is trying to nudge me in the correct direction, not active effort!

[1]: So, frankly, not that much: https://www.npr.org/sections/krulwich/2011/12/21/144066248/l...

Feel free to come find me on Masto or similar and AMA. That goes for all of you. Not auditing for free, but happy to answer questions/figure out ARIA warnings or whatever. Linting issues like that are probably stupid easy to fix once you know what's actually going on and I'll happily save you the MDN trip :)

There definitely are accessibility testers who do this kind of thing professionally. The latest episode of the Linux After Dark podcast [1] had Florian Beijers [2] as a guest who livestreams accessibility testing of open source projects and does professional accessibility consulting.

[1] https://linuxafterdark.net/linux-after-dark-episode-72/ [2] https://florianbeijers.xyz/

Lol that was me :)

Let me preface with: I’m neither a web dev nor experienced with accessibility.

Which tools did you use? I’d argue a human probably also won’t review all your alt tags manually or you could just do it yourself, too. If you have lots of them it might make sense to extract them automatically and pipe them to some language model to generate a score for each of them. Then you can review the ones with the worst scores.

It seems to me that https://wave.webaim.org/ does a good job with ensuring contrast is good, etc., as once I followed all the recommendations things are also readable when using Dev Tools to simulate various vision deficiencies.

I had a couple of such sessions as part of accessibility certification when rebuilding a largish government website years back. It's definitely worth it for understanding the why of the accessibility recommendations, rather than just following a checklist. And if budget allows to do website improvements that go beyond.

The experience was also humbling in an awesome way. I think I still haven't seen anyone navigate the web as fast as this one blind person was capable of, due to the mastery of his tools.

Indeed. I am reminded of the major catalyst that got me to become serious about learning vim: I saw a senior developer flying around in his text editor, editing things like a ninja, and I had to learn that skill. I've been extremely glad I invested the time.

Had the same feeling now three times while watching vision, impaired people using accessibility tools. They can absolutely fly through things much faster than a typical user can. Aside from the general awesomeness that is taking something that most people would consider a disability and turning it into a superpower, it makes me think that I am really missing something by not having that skill.

Has anybody done this before and can offer some advice for how to start, and where to go with it? I am a Linux-only user, which I assume is going to matter for the tooling.

I'm also glad I invested that two measly weeks back in 1994 which made me ninja.

Heh, I guess you are in fact a VI-sion impaired person flying through things when using these editors.

It's a great idea to be proactive in this area, but always make it easy for your users to report problems. People with different conditions, whether classified as disabilities or not, have varying capabilities. You might be surprised by the issues people encounter with your product, even if you follow all guidelines meaningfully (so not just with placeholders like alt="image" - yes, even then).

Source: I've been part of an accessibility taskforce at my company for a long time.

There are people in Fiverr who specialise in it. (But a lot of them will just run basic tools, so watch out) A shout-out on mastodon may give you some good leads too.

I think you are talking about Usability here.

Usability: This button is hard to understand and/or confusing to operate.

Accessibility: I cannot operate the button AT ALL, cannot perceive it, or can only do so using advanced assistive technology tricks.

I thought about it.

For example, the sidebar page tree supports keyboard navigation.

The UI library I am using, Mantine, follows accessibility best practices and has full keyboard support.

There is still a lot to do in this regard. As the project progresses, more support will come.

In the past, I built a Twitter bot (@threadvoice) to help people listen to Twitter threads in audio format ( https://twitter.com/Philipofficial9/status/11899711858004869... ). I had accessibility as one of my motivations while building it.

Also auth. I would rather just lose all my shit than try to go through the login rigamarole on either of these sites again.

Are we talking about Confluence from Atlassian’s login? What’s so bad about it? It’s usually tied to your SSO provider, so you just have to sign in to your work account. In the server days, it was connected to your AD/LDAP password.

I don’t like Atlassian products very much for a lot of reasons (each iteration of the UI gets worse), but the login process has never been an issue for me, so I’m surprised to see your comment.

Not OP, but have to use the cloud version of Jira and Confluence. My biggest complaint is that they put the "Yes! Send me news and offers from Atlassian about products, events, and more." checkbox in the place where I would expect the "Remember me" checkbox.

Absolutely psychopatic behaviour.

I can’t explain how frustrating it is on Amazon where that checkbox instead reveals your password in plain text. Super easy way to dox yourself.

How important could this be to companies really, if they are using Confluence and Notion, which are already doing this poorly.

Depends on the company. In many areas companies are required to not discriminate against disabled employees. Just like your physical space must be accessible, your digital tools must be too. Otherwise you would might, say, pass on a more experienced and knowledgeable blind candidate in favor of a less qualified sighted person, because your internal tools can’t be used independently by a blind person.

Lots of companies are technically exposed to the risks related to this kind of thing, could be legitimately sued. But they don’t always recognize this aspect of their exposure.

It seems natural to me that this sort of thing will become more important over time.

More interesting to me though is what prompted your question. Parent requested making things accessible because that’s something as individual they need and benefit from. It wasn’t about how important it might be to “companies”. Individual people need accessibility.

I understand that in the US, the ADA can make for a nasty sting which can make them care in a hurry.

Whilst important, it certainly wouldn't be the top of my list of things to tackle when getting a project off the ground

And while that is a perfectly valid stance to have on this, you'll more than likely shoot yourself in the foot if you don't.

- Wayland didn't think it was important to immediately include this, and now we have the majority of linux distributions having serious issues with screenreaders and other assistive tech. Fedora's shipped with this broken for almsot a decade. Calamares didn't think it'd be important to fix and has been broken for about as long. - Particularly now, with devs grabbing a component library on top of React with a generous helping of CSS frameworks and third-party NPM-based extra bits that are all tangled together, and what have you, if you don't vet this stuff beforehand you'll have to retrofit half your UI to fix things after the fact. That, right there, is why accessibility seems so hard to implement.

Fixing a native HTML select for accessibility is easy; it already is. Fixing some componentized overengineered monstrosity that figured they'd get to it later and as a result doesn't speak with screen readers, doesn't work on phones, doesn't work when zoomed in, doesn't respond to speech recognition software, goes absolutely nuts when the user scrolls, and doesn't let you use it properly with a keyboard... yeah that is harder :)

I think it makes sense to learn about it early and do a11y as much by design as possible. I think a universal design approach will help anyone. Many power users will appreciate good keyboard only navigation as a side effect. With a bit of a11y knowledge you might be able to catch a lot of low hanging fruits. Wouldn't do it with public procurement and overdone rigout in mind. Just spinning up a screen reader on an app can actually be a fun experience.

That’s the most common approach, but a cynical rewording of that statement is: I’m not making it accessible by default.