I love that there's a call for more UX patterns to be built into native elements, but I really wish there was a massive push to develop better a11y tooling for developers. Chromium has the A11y Tree View, but it's so noisy that as someone who isn't intimately familiar with the interaction pattern of screen readers, I can't easily digest where the issues are.
I'd love to see a purpose-built browser that "renders" your site purely by the a11y tree, but in a layout similar to how a site might look. That'd make it super easy to see missing buttons, links, uninteractable elements, etc. I'm sure there's efforts within browser developers to do this, but it's frustrating that most of the work is being spent just telling developers their sites are inaccessible rather than giving them the tooling to help make their sites accessible.
Oh my goodness. It's wonderful. This needs to be part of browsers by default! The only suggestion I have so far is it'd be pretty nice for it to be a tab in the dev tools, potentially with element highlighting as I hover over the nodes.
Actually this is not the first time someone is asking specifically about this. I haven't worked on this extension much recently, but perhaps it's time to give it more love :)
This 100%. There's the tree view and tools to make sure tags are there. Some tools to check that the site is keyboard navigable. But I still find I have to go through with a janky screen reader plugin to make sure (the best I can) that the site really works for screen readers.
The main problem is that as a sighted user, I'm used to scanning a site and discarding tons of superfluous information. If all that is read to someone it is tedious and very hard to navigate with. In many ways, the developer needs to think of an entirely new UX for a user on a screen reader. Hiding repeated elements is one of the biggest things to be done. Do the items for the screen reader have context is another. On a graphical page a button with the word "GO" might make complete sense. It makes a lot less sense when being read to a non-sighted user after listening to a bunch of other elements.
> If you’re a web developer, accessibility is literally your job. If you ignore it, you’re just a hobbyist.
Just as if you ignore security, privacy, responsiveness and performance of the site, you’re just a hobbyist. Enterprises usually hide behind budgets and quarterly numbers not to do most of these things.
Accessibility is not for “other people” or “disabled people”. There are people who tend to think that way. It’s actually for yourself and everyone else. Without accessibility features, even the average normie would have a much tougher life.
I don't get why it is considered useful to denigrate hobbyists to score internet points.
If you regularly get paid to do something, it is your job.
Maybe you are good at your job. Maybe you are not. Maybe some people think you are and others think you aren't.
If you do something without getting paid to do it, it is likely a hobby.
Maybe you are good at your hobby. Maybe you are not. Maybe some people think you are and others think you aren't.
I get paid to create, update, and maintain software. That is my job. If I'm doing my job poorly, that does not make me a "hobbyist". It makes me someone who does his job poorly.
One of my hobbies is playing guitar. And no matter how good I get at playing, until the day someone pays me to play the guitar, I'm still a hobbyist.
There are many hobbyist guitarists whose musical skill level is equal to or greater than the skill level of professional guitarists. And while you may sometimes hear a talented hobbyist guitarist lament that some untalented guitarist became wealthy playing simple songs, it would never make sense to anyone to claim that the 3 chord playing rock star could or should be denigrated by labeling him a "hobbyist".
Right, so if you believe that, then you believe someone who fails to do that is doing poorly in their job.
That doesn't make them a hobbyist. It makes them bad at their job.
If you equate people who are bad at their jobs with hobbyists, it implies that hobbyists are bad at what they do which is simply untrue. Many hobbyists are very very good at what they do and they are usually free from the constraints that come with a job (e.g., doing what your manager thinks is important rather than what you think is important).
i'm ok with pushing the importance of accessibility for "websites intended for the general public", but there are a very large number of web projects out there with a very targeted audience that simply do not have the same accessibility needs as a large retail or informational or government website. Internal webapps for known users are what a lot of us are working on, and accessibility is often not much of a concern.
> That doesn't make them a hobbyist. It makes them bad at their job.
Correct. The point is that a hobbyist doesn't have to care about it. When I write software for personal use (read: as a hobbyist), I don't worry about having good accessibility labels, or testing for localization support. When it's a hobby, I write the software I want to use.
When I write software professionally, I need to make sure it is accessible. Otherwise I have failed.
> If you equate people who are bad at their jobs with hobbyists, it implies that hobbyists are bad at what they do which is simply untrue. Many hobbyists are very very good at what they do
I see it as distinguishing between endeavors where being good is a requirement and those that are not. Of course there are many highly talented and skilled hobbyists but it’s not a requirement. It’s not even a requirement to want to get good at a hobby, though most probably do have some level of attainment in mind.
It seems like in the startup world, accessibility is about the last priority.
After all, if you're in the business of shipping half-finished software and rushing from one feature to the next in a mountain of tech debt, how on earth are you going to find the time to think about accessibility?
Internet shaming aside, ignoring accessibility for a while seems like good business sense.
Section 508 and ADA laws are quite real, and there are activists out there literally just looking for websites to sue who do not meet those requirements. You need to balance launch and revenue with the risk that you'll get sued and the cost of the consequences.
I'm not disagreeing with you, BTW... just saying that for the decision to be good business sense you need to look at the full potential impact on the business.
> YC-stage startups who got sued into oblivion over accessibility
No, because real people with problems (not lawsuit trolls) don't want your money, they want you to fix your product. Most will reach out before bringing a suit. If a suit is brought, they almost always settle if the company A) fixes the problem and commits to keeping the product accessible and B) pays the costs of the suit.
It's cheaper to fix the problems than to fight the suit, especially for a new business that doesn't have a lot of technical debt or a large corpus of inaccessible content.
> Imagine if you couldn't Show HN without thinking about accessibility and actually taking on serious legal risk.
U.S. accessibility requirements for private entities (vs. government ones) apply to "places of public accommodation." Lawsuit results have been mixed about whether an online operation, especially if it has no corresponding physical operation, count as a "place" (I think they do). Personal sites, projects will not require meeting accessibility requirements any more than your house will be legally required to have a ramp for wheelchair users.
If you're going to worry about legal risks for Show HN projects, worry more about creating privacy and security problems for users.
How does it work on the web? Would developers get an opportunity to fix the issues, or would the company randomly get slapped with a massive fine?
It seems like it would be a good way for a company to suppress competitors to a field, they could trigger these kinds of laws in up-and-coming companies.
It ends up going to the OCR (Office of Civil Rights). They will independently verify whether or not there are problems. If there are, the organization who owns the site will be contacted and made aware of the concerns. They will get an opportunity to correct the problems.
And yes, you certainly could audit your competitors products and force them down this path. I'm not sure that is a winning move, though, as all you are doing is forcing them to build a stronger product.
Usually laws like this don't apply until you're a certain size, headcount or revenue. I'm not sure if that's the case with accessibility but usually startups building MVPs can focus on the product and come back to hit compliance once they start growing.
In the physical world you can't just ignore safety and accessibility requirements because "hey, it's expensive and if I don't open then no one will be able to visit my business at all. Might as well serve some percent of the population." Websites shouldn't be any different.
But there are many physical products that can only be used by people without certain disabilities. For instance, cameras, mirrors, light bulbs and paintings require you to be sighted to get any utility from them. Headphones require you to be able to hear. Those might be extreme examples, but there are a huge number of things that you basically get zero utility out of if you don't have typical abilities in relevant areas. Should I not be allowed to sell a bicycle if I can't figure out a way to make it work for people who don't have 4 functioning limbs?
Most web sites can be made accessible simply by making them work normally and reasonably... it's generally the browser's job (and various other things like screenreaders) to make them accessible, assuming the web developer isn't doing something particularly weirdly. Isn't it?
It seems highly inefficient use of resources to have each site have to do a lot of work to support accessibility, especially if the sites are doing basic things like presenting documents. But if I make a web based paint program or charting app, what am I supposed to do for people who don't have sight? Does that even make sense?
I think you should actually read about accessibility requirements.
> Most web sites can be made accessible simply by making them work normally and reasonably... it's generally the browser's job (and various other things like screenreaders) to make them accessible, assuming the web developer isn't doing something particularly weirdly. Isn't it?
It's not the browsers legal responsibility to do so, no. It's the responsibility of the business to do that.
I'm not talking about whose legal responsibility it is, I'm talking about whose responsibility it makes sense for it to be. Anyway, if the browser did nothing to address accessibility, laws would be made to require them to do so.
It makes sense to address it universally, if possible, rather than case by case. Surely you agree that someone who simply puts a document on the web should not have to develop their own screen reader. Or should it just be businesses that are required to do so? That has obvious problems.
And that’s the reason the modern world sucks for a lot of people. Imagine living in a world where people don’t design for you because it’s not economically worth it.
At least for SaaS websites, I imagine you're limiting who can buy your software if you don't comply with relevant a11y guidelines - think government, healthcare, and some big companies etc.
The root of the issue here is that information doesn't convey the same way across all mediums.
If you have a graph that is reducing 1000 words to one image, the 'solution' to make it 508 compliant is to put the raw data in a way the screen reader can read it out. In the specific situation where I was asked to do that, I realized the goal wasn't accessibility, it was to comply with the regulation.
I can't help but disagree with the premise: at a basic level, accessibility is not hard. It is hard to consistently check all the boxes for WCAG AAA, but let's be honest, this is not where the trouble starts. Most sites fail on basic issues and this isn't a for a lack of resources. Case in point, Bootstrap, the most widely used frontend library by far, has only recently started thoroughly addressing accessibility concerns in their code examples and snippets. Prior to this it was a mix and match of the good, the bad and the ugly. I completely agree with another commenter that tooling does have a very long way to come with regards to accessibility. Better tools make for better software, as witnessed by linters, fuzzers, testing frameworks and the like. But even more so education. You can easily teach someone with basic knowledge of web dev the core concepts of accessibility in a day, a crash course in even less time would also be completely manageable. Sadly, this is not a topic that I've seen any uni or code boot camp cover in a reasonable stretch.
This has not been my experience based on my involvement in accessibility efforts at two medium-to-large companies that decided to make their existing web-based products accessible to blind and low-vision users.
In one of the cases we brought in accessibility consultants, created a usability testing pool of users with various vision and motor impairments, conducted training for dozens of front-end developers, revised our framework, and made changes to many product UIs. After several years and millions of dollars of effort a few products were functionally usable by blind and vision-impaired users. Note that this is distinct from being WCAG compliant, which is a good place to start but doesn't guarantee your product is actually accessible. I think it was the right choice and it made our products better for everyone, but it was Very Hard and it required buy-in up to the executive level.
I'd consider it grossly unfair to blame individual developers or call them "hobbyists" solely based on the fact that they worked for years on products that did not have good accessibility. If anything, the assumption that accessibility is something an individual developer who is sufficiently "professional" can just choose to add to their interfaces makes me suspect either the author lacks experience working in a medium/large development organization or they are just targeting WCAG compliance rather than functional accessibility.
I agree. For anyone creating websites (not web apps), accessibility is not that difficult if you follow HTML5 semantic markup. Or put another way, you don't have to 'bolt-on' accessibility as another layer on your markup - accessibility comes already built-in; you get it for free.
Where it isn't accessible is when you're using a JavasScript framework that generates non-semantic markup. Or you're using a CSS framework and your HTML markup is littered with endless <divs> rather than HTML semantic tags.
Here's the thing: HTML is easy. It's CSS that is the monster. (But bearable in its modern incarnation with features like Flexbox and CSS grid.)
I'm all for arguments in favor of accessibility. That being said, this article is the exact opposite of how to get many people (like me) on your side.
> accessibility is literally your job. If you ignore it, you’re just a hobbyist.
ah yes, of all the issues and features on the list, this is the one that defines whether or not I'm doing my job.
Point being, I don't think an article like this actually makes accessibility more of a concern overall... but who knows? Maybe people are more responsive to this than would be intuitive to me.
I agree -- the tone of this article doesn't help, and it is mostly aimed at the wrong people.
In reality, I was always told to hustle hustle hustle on the design. FUCK accessibility.
I would have to counter to my masters with a stick (that Target ADA complaint) and a carrot (almost all accessibility is a medium-grade form of whitehat SEO that will increase rankings). The stick wasn't usually taken as being important, but that carrot ... whoo! Nibble nibble.
In my web design days, I would love for the chance to linger, to tweak, to test on browser after browser, to poll people at random. Breaking the design, then repairing it. However, we're all so busy, aren't we?
I have done various accessibility spiels on HN before.
I think most people who are ... (and heaven help me, what do we even call this now? "Webmaster" is out, "web designers" seem to focus on almost anything else in the real world, "programmer" is too broad ...) people who are responsible what actual HTML tags and CSS attributes are assigned in the final output either care about this to some degree or simply haven't been introduced to the concept. Overall, we'd rather close our tags and put in the alt attributes and so on. There's nothing malign about it.
However, the people who decide what our time will be spent on dismiss even the barest accessibility as soon as it hits their radars. Even when I could get "through" to them, well, it's all about what the client wants. And accessibility is a concern that ranges deeply enough through our efforts that we cannot simply squeeze it in as five percent, or a skunkworks project.
I help out a little old lady (eighty-eight this year) and my mother with computer "stuff," and that's a whole dimension of accessibility which just gets ignored. Not every user of an application is some sharp-eyed twenty-something with fine motor control and an ingrained habit of scanning the UI for changes, and yet these people are effectively ignored.
I am out of the webdev biz, and happily so, but this remains a point of lingering bitterness.
The phrasing is certainly provocative, but a truly conscientious person would pick a side on the basis of merit. There's hardly any point in reasoning with someone who's obviously looking to make a decision based on the emotions evoked by an article.
The thing is there isn't much in this article other than emotion. A sound thesis would examine (at least seemingly) legitimate arguments against accessibility.
Another comment on this thread points out that designing/implementing accessibility comes at a cost. Why would money-tight companies use resources to do it?
Maybe mention the market share represented by people who need accessible sites. Maybe provide the numbers for how many websites are truly accessible. Highlight the fact that by spending resources on it it could almost be akin to targeting a niche with very little competition.
That's how you convince conscientious people, not by saying "if you don't do it, you're a fraud".
"In many countries around the world, accessibility is a legal requirement." Would have been nice to name a few. AFAIK it's not that clear cut in the US for example. It depends on your industry, your physical presence (judges seem to apply the rule of thumb of "if you have accessible buildings to do business, your website must be too", etc).
If you go through the specs they're quite overwhelming, the basics are ok and perhaps that is essential to include on any design, but once you step a bit outside of hyper text it's really complex (or just want some degree of interactivity), as an example, hidden aria elements can't have focusable elements inside them, so if you have panels that hide/show content you have to change the aria elements as you go, hey js, not sure also how it plays out for a screen reader, does it just abruptly stop and starts on the new panel once it goes to a shown state? Then you need tools, specific ones to test it, then you need to understand all the nuances between html and specifics of aria tags, and how it all plays together, and then css, that has to play visually with what the accessibility requirements are to make it consistent, then you need JS for anything interactive to change those things.
Then form invalidations, input patterns, and titles, and outside of the form errors (returned on validation by the backend), then dropdowns, buttons that link, or do actions. And then localisation. Probably there's more.
No idea how to solve those to be honest, but as it's it definitively looks like a full time role with enough domain specific knowledge needed to do a decent job.
For me, the biggest hurdle has been education and awareness. At least a few years ago, the courses and resources I used to learn about web development didn't cover accessibility, and I had to learn about it after the fact. I'm glad to see more introductory resources cover it now though, like the MDN docs and web.dev.
Thank you! What a breath of fresh air this essay is.
Accessibility is ability to access, regardless of method, configuration, and skill.
Telling the user their browser, device, or configuration is not good enough, in a situation where you could have bent over backwards a little bit and made it work for them, is hobbyism, I agree completely.
If a device is able to connect to your site and request the page, you should be able to accomodate it, regardless of age, configuration, CLOCK SETTING, and so on.
ANY BROWSER is not a pipe dream, but an attainable reality, and just plain nice and polite.
I've been able to almost single-handedly achieve support for all major browsers since Netscape 2.x, so I don't think it's beyond someone like Google to achieve the same. It makes me feel embarrassed for everyone involved when google.com search results are broken in a browser less than 10 years old.
Personally I'm for an opposite approach - content that I produce is already a free gift to the world, so it's on a user to find a way and means to consume it. Should be a bit of a challenge, really.
It is unreasonable to expect hobbyists to shoulder the maintenance burden of everything they share with the world. It is fun to build things, it isn't fun to maintain things, but that doesn't mean that what you built can't have value for anyone without you maintaining it.
That's perfectly fine. The SVG is within a link tag with the description "Go Make Things" and is purely decorative. It shouldn't be communicated to accessible technology.
> If what you built isn’t accessible, it’s not complete.
I'll be here waiting until someone builds an accessible sketchup to prove this point. Until then, I'll call it for what it is, idealistic bullshit from people with limited experience of what the web can do.
But it's not my job! My job is what my team tech lead says my job is, what my CTO says my job is, what my team agrees my job is. There is a million vital things we could build into the software, why is this one the uniquely important one? Go change business culture first and, when you're done, come back and tell me what my job is.
- Large corporate customers have their own accessibility requirements for software they purchase, so if you want their business you have to be serious about it
- You will have a slightly larger potential user base
- Generates goodwill for the business
- It helps your existing customers and fully abled users as well. Everyone can appreciate sensible keyboard shortcuts, tooltips, voice narration, good color contrast, font size etc.
I run a SAAS product that helps digital agencies scan/monitor/remediate sites for accessibility issues, and unless one of their clients was recently sued I have a pretty low success rate getting them to start a trial.
There could be a lot of other factors at play (I'm terrible at sales, my landing page isn't good enough, etc), but my sense is that it's not something that is on the radar for most small/medium agencies and freelancers.
These are the folks that are building a whole lot of the web, including the local businesses that people using assistive technologies would really like to be able to access easily.
Perhaps your marketing efforts are directed in the wrong place. You are trying to convince digital agencies that they will be able to convince their customers of the value of accessibility. This sort of second order education is hard to pull off.
You might have more luck trying to raise awareness among businesses directly. If businesses start asking their agency/developer about accessibility, you'll probably see better uptake rates.
Definitely a possibility, as it not a route I've tried. As I mentioned I'm terrible at marketing and sales ;).
My own experience working in a digital agency was pretty much the same though. If a client was sued or received a demand letter, they came to us asking about accessibility. When we brought it to the client, they often just saw it as us trying to upsell them.
In the end, we just shot for WCAG AA on everything whether the client asked for it or not and built the additional testing into our costs.
Making your website and apps usable to the highest number of people possible, and of course not opening yourself up to litigation. I've been on the receiving end and it is not fun!
A lot of accessibility best-practices also benefit practically all of your users; keyboard navigation, proper contrast, etc. are a net positive to everyone.
I can't personally say for software, but in any other arena 'accessibility' generally makes for better products/services. Curb cuts, for example, serve those with mobility issues. We think people permanently in wheelchairs, which is true, but pretty much every human is going to have mobility issues at some point in their life - injured, pregnant, just carrying too much, dead drunk, etc.
So in short the business value of accessibility is similar to the business value of quality.
it's easy to argue that accessibility is your job if you're billing yourself as a ui engineer, but i fear a lot of these poor saps are being paid to use js for a lot more than just ui
Accessibility is the hill upon which most independent UI toolkits like Dear Imgui die. Once you look into accessibility you are restricted to native, Qt, or Electron for any serious work.
Yes keep insulting working developers accessibility advocates, that'll surely work this time.
Seriously, accessibility is hard. There's no single standard or spec I can look at, a bunch of disabilities I've never even heard of, no standard test suite to pass, and a bunch of specialized hardware I should be testing on but can't afford and even if I could I don't have time. Reading accessibility blogs by professionals in that field is a minefield since they aren't even able to come up with a coherent narrative among themselves.
Know what my job is? Responding to the pile of functionality requests my paying customers have asked for. Know how many of them are related to accessibility? Zero.
I WANT my application to be accessible. It's good karma, it's good for people I know who are disabled, its good for my customer's employees, its good for getting government contracts. But accessibility is difficult, expensive, and meshes poorly with the short development cycles that are the hallmark of the startup space.
So how about you assholes stop insulting me and start coming up with some solutions?
I'd love to see a purpose-built browser that "renders" your site purely by the a11y tree, but in a layout similar to how a site might look. That'd make it super easy to see missing buttons, links, uninteractable elements, etc. I'm sure there's efforts within browser developers to do this, but it's frustrating that most of the work is being spent just telling developers their sites are inaccessible rather than giving them the tooling to help make their sites accessible.