Hacker News Reader

Comment by logicalmonster | Hacker News Reader

I think we can all understand and agree with wanting to help disabled people as well as possible, but there's no clear binding standard for what constitutes an accessible website. Two different experts can look at the same site and give 2 different opinions about what's accessible about the experience or not or how to best improve it.

Additionally, technology changes all of the time: new screen readers and new web APIs come out and and more. Best practices don't necessarily get perfected on day 1. Do you expect every website to get continuously rewritten just to keep up with the latest opinions on what's best? This is complex enough for large tech companies who can write a blank check for a large team of full-time developers who can work full time on nothing but accessibility, let alone a little corner cupcake store who managed to save up enough to build a custom cupcake website or something. Do we seriously expect every small non-technical business eking out a living with a small store to be experts on every facet of accessibility?

If we're going to cover websites under the ADA, I think there should a lot more leeway for "reasonable accommodations" that can be made. If a small business can't make an accessible order form for some reason, they should be able to take orders over email or the phone or something before getting sued for this.

View on HN

Blind developer here. Even though web technology might move fast, things move slowly in the world of accessibility.

You're saying it's too hard to catch up with the latest technology - I wouldn't agree with this in the context of accessibility. What happens in practice is that a frontend developer develops for example a fancy combobox that needs to be clicked on with a mouse without thinking twice. And that combo box stays on the website for years. Now suppose that's a website to book flights. I go there and I spend half an hour trying to click that damn combobox with a keyboard and still it wouldn't allow me to select anything. Well too bad, it turns out I cannot fly XXX airlines. Or I'd have to wait for my sighted assistant who comes once a week to deal with these websites.

And what if I told you that half of websites on the internet are like this - that is not accessible or extremely ahrd to use? I have to avoid certain online stores, certain airlines, certain hotels because of that. Finally I work in faang company and so many internal web tools here are not accessible. I found my way around, but I have seen blind people being fired for not being able to perform while every other tool that is required for you to use doesn't work with your screenreader and nobody cares to fix that?

And what's the price to fix it? Educate developers to use simple combobox instead of fancy one? Try to test it with keyboard? Are blind people really asking for too much?

And also regarding getting sued - I have no idea what kind of lawyers can sue for this, I have never heard of actual blind people being able to sue someone because the website was not accessible. If that was the case I would be able to sue half of Internet including Google, Facebook, Amazon, and so many more. I suspect certain lawyers are taking advantage of the system - e.g. there was this american life episode years ago about a lawyer who is specializing on suing hotels that claim to provide acomodations for disabled people -wheel chair users - and they don't satisfy ADA requirements or something. I suspect this Domino pizza lawsuit was initiated by similar type of ADA troll lawyer. Don't compare blind people to troll lawyers!

I mostly agree… but one thing:

> And what's the price to fix it?

I’m currently doing accessibility work with an in-house web framework of reasonable complexity. 90% of the accessibility issues are relatively straightforwards. Things like keyboard usability are easy to explain to devs and behave fairly consistently across browsers.

But the last 10%… things like “what should happen to focus when you open a modal?” get messier fast (the ARIA docs give several different behaviours for several different scenarios, which means every dev who wants to open a modal needs to understand enough to correctly select the behaviour for their circumstance), especially since different screen readers can behave in different ways when encountering the same content. The cost to investigate and properly solve these can be nontrivial.

That’s not to excuse people who don’t even try for that first 80-90% of the low hanging fruit… but please forgive the designers and devs who fall short of the last 10%!

As a perfectly-sighted user: please don't use modals, they're basically always very frustrating.

There are lots of scenarios where a modal is the expected way to accomplish a task. Preventing irreversible errors (Are you absolutely sure you want to delete this user’s data irreversibly?), save/load dialogs, etc. Modal overuse is a real problem (and one we’re addressing in our product), but there are some situations where they solve a real problem.

The last 10 percent are hard. Welcome to software development.

Welcome to the world

OP's point is that most websites, in their experience, fail to get the easy 90%. If what you've got left is a few focus issues, it sounds to me like OP can at least accomplish their task.

> Blind developer here.

HN users' tendency to opine about things they know nothing about is really aggravating here. You and a few other blind users come in and share your experience, only to be told by a bunch of people who have never used a screen reader in their lives that you're wrong. How weird.

Just know that a lot of us who don't comment are taking notes of what you say. :)

The standard typically referenced in legal cases is the Web Content Accessibility Guidelines, Level AA. WCAG guidelines are generally clear and straightforward. Showing a good faith effort to comply with those requirements, is the bar for reasonable accommodations.

https://www.w3.org/WAI/WCAG21/quickref/

The few areas where subjective judgment applies and two experts might reasonably disagree are unlikely to get you sued.

> If a small business can't make an accessible order form for some reason,

There’s no reason for any web developer to make an inaccessible order form in 2022. It’s a form. Put labels on your inputs. Use semantically appropriate HTML tags. Do validation before the user submits.

> There’s no reason for any web developer to make an inaccessible order form in 2022. It’s a form.

Well, that's OP's point - that's your opinion that it's easy. Maybe it's someone writing their own small business website for the first time and it's not so easy for them. They'd be more than happy to take the order over the phone for anyone unable to use their website. But it would be real shitty for their first official lesson in web development to be in the form of a court summons.

But perhaps that's on purpose? Even on HN you will occasionally see people who think software engineering should require a license. Perhaps this is a way to set up barriers to scare people away from making their own websites?

It's pretty similar to opening a physical store and not making the entrance accessible.

Not really, because we can all agree that the entrance must be at least 36 inches wide and at an angle of no more than 10 degrees (or whatever). Those are physical properties that can be measured.

Versus web accessibility guidelines are a collection of opinions and "best practices." Harder to measure and evaluate.

Not really - it's painfully obvious when a web developer takes no regard for accessibility or usability and instead wanted to create something that looked fancy. Look no further than people who replace `alert()` with a half-assed replacement that accomplishes 10% of what `alert()` does in 7 characters.

All I can say is that I'm glad physical accessibility isn't codified by "I'll know it when I see it" standards.

You kind of make my point though - sure, it's obvious when it's wrong. But it's not obvious if it's right, which is the actual fear. It's not even clear if it's possible to conclusively determine that it's right.

Can you give an example of what you mean - a scenario where WCAG guidelines are too ambiguous?

https://www.w3.org/WAI/WCAG21/quickref/

Sure, any time:

> text can be resized without assistive technology up to 200 percent without loss of content or functionality.

What does "without loss of content or functionality" mean? If the resized text flys off the side of the screen (but there's a scrollbar now), is that a loss of functionality? I sure can't read it as quickly anymore, because I have to scroll to it. So that's less functional to me, but that's my opinion. And there isn't a layout solution to that, because by definition making text larger will mean less text on the page, assuming full-page content.

Does "without assistive technology" mean my website needs to manually implement a Size Up/Size Down control, or can I assume your browser has it built in?

You might consider that pedantic. But I can take almost any of these guidelines and ask the same questions. And the answer is always something like "what a reasonable person would think." But we're developers, and highly disturbed by ambiguity. So saying "the law is to follow these guidelines" doesn't fit right when the guidelines are not empirically defined.

> For the visual presentation of blocks of text, a mechanism is available to achieve the following: Foreground and background colors can be selected by the user.

Does "use an extension for your user-agent to swap out the CSS" count? I can't think of a single mainstream website that lets me choose the color of my text.

> Web pages do not contain anything that flashes more than three times in any one second period.

What is a flash? What is an anything? Can I embed a flashing YouTube video in my user-generated content that I post to make your website in violation of the WCAG? Do you have to implement technical countermeasures to prevent me from doing that? Does YouTube have to prevent users from uploading such content? These are the kind of questions that have to be answered before we could seriously consider this as practical law.

The WCAG guidelines do a good job of answering questions like these, in my experience.

Regarding resizing text, the WCAG guidelines provide the following example of a website that meets the standards: "A user uses a zoom function in his user agent to change the scale of the content. All the content scales uniformly, and the user agent provides scroll bars, if necessary."

https://www.w3.org/WAI/WCAG21/Understanding/resize-text.html

(There is also a note under the guideline that due to widespread confusion on this specific rule, as long as you meet the basic criteria listed under "sufficient techniques" you are considered OK.)

> Does "use an extension for your user-agent to swap out the CSS" count?

Yes: https://www.w3.org/WAI/WCAG21/Techniques/general/G156

> What is a flash? What is an anything?

A flash is "a pair of opposing changes in relative luminance that can cause seizures in some people if it is large enough and in the right frequency range" according to the definitions listed here, along with links to more detailed explanations and examples:

https://www.w3.org/WAI/WCAG21/Understanding/three-flashes-or...

> Can I embed a flashing YouTube video in my user-generated content that I post to make your website in violation of the WCAG? Do you have to implement technical countermeasures to prevent me from doing that? Does YouTube have to prevent users from uploading such content?

Clarification on user generated content is part of the WCAG 3.0 working draft, which you can read here:

https://www.w3.org/TR/wcag-3.0/#user-generated-content

This is always the trade-off with regulation and whichever approach a regulation takes there are always people, sometimes (usually?) the same people, who will claim the other approach is the only viable option.

If the regulation is written with specificity, e.g “Must use size 12pt Times New Roman font” then the argument is: “But this one-size-fits-all approach doesn’t make sense for my $business. It’s not that I don’t want to comply but as a business owner I need common-sense rules that give me leeway to implement them in a way that makes sense for my company and my customers. Otherwise I risk getting sued and that wouldn’t be fair.”

And if the regulation is written with flexibility, e.g. “Must use a legible font of reasonably appropriate size” then the argument is: “But I just run a $business, how am I supposed to know what font is legible and what size is reasonably appropriate? It’s not that I don’t want to comply but as a business owner I need guidance so I know what it is I’m supposed to do. Otherwise I risk getting sued and that wouldn’t be fair.”

And around and around we go making painstakingly incremental progress because of bad-faith arguments.

HN would fail the accessibility guidelines with the low-contrast downvoted comments.

"People with limited vision or color blindness cannot read text if there is not enough contrast between the text and background (for example, light gray text on a light-colored background)."

Yep, and the horrifically small and close together click targets. Due to its simplicity however, HN is already heads and shoulders above so much of the modern web in its a11y-friendliness.

It's interesting that you are mainly considering the experience of a hypothetical small business owner and what they would be happy to do, and not the experiences of disabled people, and what's easy for them.

It's a lot easier to fix the issues the Justice Department mentions, and it's really a pretty short list, than it is to live with a disability. If your business is open to the public then it has certain responsibilities under the law.

Anyway phone calls don't necessarily work well for deaf blind folks, people with disorders like ALS (Stephen Hawking etc), and some folks on the autism spectrum.

>It's interesting that you are mainly considering the experience of a hypothetical small business owner and what they would be happy to do, and not the experiences of disabled people, and what's easy for them.

The reason you think about this from the perspective of the small business owner is because if it's too overwhelming/difficult for the business then they just won't have a website at all. Then accessibility of the website doesn't matter, but everyone is worse off in this outcome.

They might put up a page for the business on Facebook, but if you're not on Facebook then tough luck. Or maybe there's no page at all and you have to go there in person to find out basic information like when the business is actually open. In these cases nobody wins. Even a broken website that's only partly usable would've been better, but that would be a liability for the business.

I mean those are possible outcomes. It's also possible they may make simple changes and have a more accessible webpage.

Given they already have a site and pay for hosting and a domain name, that seems like they might see having the site might be seen as a sunk cost.

Agreed, but keep in mind that person is already technically required to follow standards for things like PII, sales tax, security etc. in addition to accessibility. Small businesses can outsource these requirements to a service like Shopify that knows how to handle them. If you build your own site, then not taking the time to learn and address these issues will always expose you to some legal risk.

This just means that you're asking for all businesses to end up using <the service> that will inevitably turn into a Facebook level service. But everyone will be forced to use it, so there's no choice.

Every business should have a website. But with the ever-mounting requirements it's probably safer for them not to have a website at all. There's no guarantee Shopify will fulfill all the obligations after all.

You're also right about having to comply with taxes. Those are already burdens that will stop some people in their tracks regardless whether their business idea is viable or not.

I just skimmed over the WCAG quick reference with a focus on just the level A and level AA items. I have to agree with thorum on this one - the guidelines are specific and straightforward. For a basic order form with no audio or video on the screen, seems pretty easy to me. Yes that is an opinion, but an opinion based upon this very specific set of testable guidelines.

https://www.w3.org/WAI/WCAG21/quickref/

"It's hard" doesn't generally fly as an excuse; it certainly won't in court. If you're a web developer, accessibility is part of the job. If you're not, you can buy that expertise either by using a SaaS or hiring a professional.

And if you bother to read the guidelines, they are relatively simple. There are regulatory bodies that are legal minefields and whose certification process depends partially on the whims of individual auditors (e.g. HIPAA), but WCAG is not one of those.

> "It's hard" doesn't generally fly as an excuse; it certainly won't in court.

ADA requires reasonable accomidations, so it's hard is a reasonable excuse. If the accomidation is too expensive or too time consuming, it might not be reasonable.

Sure, but what you're saying can be be interpreted both charitably and not. The charitable interpretation is for scenarios like focus wrap-around in modals. It's possible to navigate by tabbing over focusable elements hidden behind the modal until you're in the modal again and it's sufficiently difficult to make focus work 100% correctly without extensive testing.

But if you're trying to argue in court that your submit button can't be activated without a mouse because doing so is too hard, that's likely not going to pass muster, since virtually every other website on earth can easily figure out how to do it.

Is it easy for someone running their own small business website to have a working feedback/contact page? Working encryption? Freaking readable type for seeing people? And yet if a business website didn't have these and they lost sales over it, would people blame users or say that the owner should find fixing certain things about their website as being their responsibility?

A lot of people would conclude that the owner should be able to decide whether to do anything about it.

>Maybe it's someone writing their own small business website for the first time and it's not so easy for them.

Ok, well some points though:

1. maybe someone shouldn't write their own small business website in the same way they shouldn't build their own entrance to the store.

2. someone first starting out should probably just make a simple html form. If so they are probably more likely to be accessible than many solutions made by big companies.

3. someone first starting out will even more probably choose some WordPress solution and that will probably be accessible enough to also meet the needs of their small site.

4. It is unlikely anyone is getting sued if they have made an effort to make things accessible, in your imagined scenario the novice making their own website for their cupcake business or whatever (and who does this, it's not 2002 anymore, it's 2022) don't know enough to think hmm, I better run this bit here through a screen reader just to see it works as i think, which is why my point 1 stands, the internet is now such a busy place that they should no longer build the entrance to their store wild west style even if they have the ability, but at least hire someone to do it who should be able to think of I better run this bit through a screen reader for them.

> maybe someone shouldn't write their own small business website

Youch, there goes a lot of literally world-changing startups, had this rule been in place in the past.

well in the context of the discussion it sounds like the idea is that the mom and pop cupcake store owner decides she needs a website and does it by getting out a your first website for dummies from the library written some years ago.

I mean in the case of Zuckerberg I guess he should have written his first website, although I don't think he considered accessibility at the time.

In the case of me and a lot of other people on HN, yes we should probably just write our own website, and I know in my case I will run it through Voiceover and make things work well enough that I doubt I would be sued under any EU or US legislation.

finally though my example of the wild west and the modern day, at some point things become so settled that it no longer makes sense for people to build their own thing unless that is what they do professionally, the analogy does not hold perfectly of course because websites are not physical buildings and someone can make a perfectly good and serviceable website for people if they use no JS, and no CSS that moves things into the order they should be in naturally or that makes elements of one sort resemble elements of another - for example no CSS that makes divs work as headings.

But in a lot of cases nowadays things need to be done by a professional, the adoption of accessibility codes just increases the requirement for professionalism slightly more.

Sacrificing people at the margins at the altar of holy capitalism is not exactly a system I'm excited about.

As a rule, accessibility is an afterthought in our industry. I would be more sympathetic to complaints if companies were making an effort. Even large tech companies fail miserably. This just reads like FUD.

The cupcake store can afford to install grab bars in its bathrooms; it can afford to hire a competent web designer. Wordpress, Squarespace, Shopify, etc. should all be accessible by default.

There is plenty of leeway for reasonable accomodations.

Hit the nail on the head. There is no guarantee that a website will be functional or work correctly for those without disabilities, much less be designed in a user friendly easy to use way. When does a bug or bad design choice impacting screen readers constitute discrimination or failure of reasonable accommodation?

The answer is nuanced and will depend on the history of the website and not just the current state. Is the site always buggy for everyone? Is the site confusing for everyone? How do the developers respond to bugs/feedback for general bugs vs bugs impacting accessibility.

Of course if you completely ignore accessibility that is much more straight forward.

> There is no guarantee that a website will be functional or work correctly for those without disabilities, much less be designed in a user friendly easy to use way.

I wonder if any ADA defense attorneys have tried this angle. “We aren’t discriminatory, your honor, our website is a terrible experience for all of our users.”

> There is no guarantee that a website will be functional or work correctly for those without disabilities, much less be designed in a user friendly easy to use way.

Your comment made me wonder if this will lead to the situation where some businesses will just opt to have 2 different versions of their website, one designed primarily to hit the accessibility requirements, and the other one made for users who do not require accessibility accommodations. Kinda similar to certain businesses which, in the past, used to have separate mobile versions of their websites (before reactive website layouts became easier to implement and more commonplace).

As long as those accessible versions of websites comply with legal accessibility requirements and provide the exact same services as the non accessibility-targeted website versions (i.e., features and functions are not exclusively present in one version but not another, so you can perform the exact same functions in both), that shouldn't cause any legal issues, right?

Note: I am not trying to come up with some "workaround" to "beat" the requirement. I think that, overall, accessibility is a great cause, and I am not taking a stance on this issued guidance from the Justice Department. I am just trying to see where this could lead us, based on my current understanding of this guidance.

WCAG does allow for “conforming alternate versions”[1]. However, it’s one of those areas companies think they’ve found a loophole and then quickly realize how impractical it is to maintain two entirely different applications.

If you’re going to go through all that effort, why not just build and maintain one application that is more accommodating?

Alternate versions are typically best reserved for minor feature flags (e.g., user given option to change colors to a high contrast non-brand palette), for instance, than wholly separate versions.

[1] https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#...

> There is no guarantee that a website will be functional or work correctly for those without disabilities, much less be designed in a user friendly easy to use way.

Is this a strawman argument by someone who doesn't understand accessibility or do you have actual examples?

Serious question, are you really asking for examples of broken sites? Have you never used a site that was broken, took forever to do something simple, or was otherwise not acting as expected?

Just this week the LMS our company uses accidentally removed existing functionality we relied on to sell courses. They didn’t purposely remove the feature, but instead a UI overhaul never included the UI for it. The feature was still available in the backend and for the legacy design, but they just forgot to include it in the redesign.

Also, present your argument for why I don’t understand accessibility.

> there's no clear binding standard for what constitutes an accessible website

>Do you expect every website to get continuously rewritten just to keep up with the latest opinions on what's best?

The DOJ cutes under "How to Make Web Content Accessible to People with Disabilities" the W3C Web Content Accessibility Guidelines (WCAG). These recommendations aren't new, but if you find them lacking, then what improvements would you suggest?

> new screen readers and new web APIs come out and and more.

New web APIs, for sure. But the screen reader market is not fast moving, in terms of new software being adopted. The line-up of the most used three screen readers (NVDA, JAWS and VoiceOver) has not changed in over a decade, despite the individual software applications themselves undergoing changes, and of course the market share of each one increasing and decreasing over time.

> Do we seriously expect every small non-technical business eking out a living with a small store to be experts on every facet of accessibility?

No, but I also don't expect such a business to be up on the latest in security, PCI compliance, GDPR conformance and more. For that reason, they are probably either:

1. engaging a web design/development agency; and/or 2. using a pre-defined platform, like Shopify.

In the former case, I do expect anyone making money from website building to at least give accessibility some thought. For the latter, Shopify is one of the businesses you describe, as a "large tech company who can write a blank check for a large team of full-time developers who can work full time on nothing but accessibility". As such, they absolutely should be setting up small business owners for success, by making their out-of-the-box themes, widgets, flows, etc. reasonably accessible to the widest possible audience.

Ah, so that is why small businesses so commonly do not have a website and use Facebook instead.

Most small businesses want some solution that Just Works^TM. The less time and money spent, the better.

Most small businesses will also not jerry-rig their own payment processors.

Can we acknowledge that there’s more than 1 important competing “socially good” value that’s in conflict with your prescription?

Your prescription is a large step towards the death of what portion of the free and open web still exists. Just saying “build your business website on some default storefront or walled-garden by Facebook, Amazon, Shopify, or some other mega corporation’s platform and don’t change 1 line of code or risk legal obliteration” is close to a death sentence for an independent web.

Is it not valid to point out that doing our best to maintain an independent web is also an important value as well for the world, for disabled people, and future generations?

It is not valid to say that the value of an open web trumps the value of people being able to use the open web.

Inaccessibility can prevent a person from getting a job, or cause a person to lose their job if the requirements for that job change (I've seen it happen). What is the equivalent personal cost of further centralizing the web?

> Do you expect every website to get continuously rewritten just to keep up with the latest opinions on what's best?

My understanding of webdev is sites are getting continuously re-written anyway to keep up with the latest opinions on what framework is best.

You make it sound like it's completely arbitrary whereas it isn't. I feel like the only conflict might be what helps neuroatypical people might be different than what helps deaf people or what helps blind people, etc. Unfortunately, "disability" is a very broad term an encompasses hosts of people. That said, the "churn" of "opinions" on what helps disabled folks is nowhere near as arbitrary as whatever new hot stuff js framework is out there and yet you people keep up with all that somehow.

There are some things, such as putting text inside a bitmap image with no alt tags, that are fairly objectively going to make any sort of accessibility software much less reliable and more complicated.

But what about things like "most screen readers don't support the new WebX API that came out six months ago?" Where's the line between what website developers need to do to be compatible with screen readers, and what screen reader developers need to do to work with the websites their users want to use?

If you are providing a service it should be accessible. If you are using a fancy API that is not accessible (yet) you should provide a fallback, or—better yet—use the fancy API to progressively enhance the service.

If, however, you are making a fun little game which relies on Web Audio API, and there is no point in playing the game without headphones, then your good. The line is pretty obvious in most cases. Or at least you—as a web developer—should know it when you see it.

> Do you expect every website to get continuously rewritten just to keep up with the latest opinions on what's best?

I mean let’s be honest we’re constantly doing that anyways

Regarding your last point, I think that is already the case? Dominos was sued because their site/app was not accessible, and lost, partly because the court ruled that calling in an order was not an adequate alternative because the plaintiff was placed on hold for 45 minutes multiple times.

https://www.jdsupra.com/legalnews/court-finds-domino-s-pizza...

Reply on news.ycombinator.com