Accessibility is the hardest thing for me about making things for the web
gomakethings.com
gomakethings.com
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.
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.
Link: https://chrome.google.com/webstore/detail/aria-devtools/dnee...
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.
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".
I think the point is that, if you're professionally developing software that interfaces with humans, accessibility is part of your 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.
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.
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.
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.
The general point is that "I don't use a particular OS" is wildly different to "my body does not work that way".
Also, when you have financial access issues, it implies that you have access issues for everything in life, including the basics like medical care.
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?
> 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.
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.
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.
It just kind of feels like a joke, when almost any webapp in existence is not compliant and there is no enforcement.
It also goes against the hacker ethos that we should be free to build and share without credentialing or licensing.
Imagine if you couldn't Show HN without thinking about accessibility and actually taking on serious legal risk.
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.
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.
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.
Right after security.
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.
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.)
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.
> 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.
"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).
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 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?
Eventually I had to turn to self-directed unpaid development in order to do work I wasn't ashamed of.
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.
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.
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.
Don't you want someone to find it and appreciate it?
Or are you only interested in readers without disabilities or disadvantages, and who are willing to put in some busywork?
This is the way accessibility alt text should be provided with an SVG and highlights that even the simplest things are easier said than done.
Aren't you supposed to use lists for that?
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.
A lot of accessibility best-practices also benefit practically all of your users; keyboard navigation, proper contrast, etc. are a net positive to everyone.
- 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.
- It's generally the right thing to do
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.
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.
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.
I imagine this strategy is what remained after realizing not enough clients want to pay for accessibility.
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?