Hacker News Reader

Comment by curryst | Hacker News Reader

This is a messy situation. On one hand, I totally get that the internet is a massively important portion of most people's lives, and people that need special accomodations should be able to participate. On the other hand, accessibility still doesn't seem to be easy to implement. I don't work on the frontend, so I could be wrong, but last I looked, it seemed heavily manual and somewhat hard to integrate. It will be expensive to implement, at least until someone makes a better abstraction.

I suspect the Domino's ruling will be the winning one, but I don't know where that line gets drawn. Does my blog have to support accessibility? I don't sell anything, but it is public. Is the neighborhood softball league going to have to implement it? Commercial entities will probably have to comply, but I'm curious what the impact on the rest of the landscape will be.

View on HN

The difficulty really depends on how much you deviate from the browser defaults. For example, if you use the default datepicker it's accessible by default, if you build your own you'll need to annotate the states with accessibility attributes.

I don't think it's as difficult as you make out to draw a line. An analogy: you can't have only a men's restroom in your Dominos store, but if can in your shed in your backyard for your friends if you want.

Edit: Now I've read TFA I learned the law already has a perfectly reasonable sounding standard that was ruled not to apply to the internet in this case

> Winn-Dixie had argued that the law defines "public accommodations" to only include physical locations like a store. A website isn't a physical location, and hence it's outside the scope of the law, the grocery chain argued.

I'd hate to see this become the standard. The build-in browser datepicker is utter shit. There's a reason nobody uses it. Frankly the whole HTML form spec is a world of crap for what users are expecting from UIs these days. Being legally limited to what the WHATWG manages to agree on and ship in a browser would be a huge step back for web applications.

The default is hard to use. However, I've found it better than the open-source alternatives I've seen (mainly AirBnB datepicker) if you test across {Chrome,Firefox}{Desktop,Mobile}.

I also wasn't suggesting the built-in should be mandated, just that if you replace it you either provide a way to downgrade to the built-in or make your replacement at least as accessibile. If you make your replacement usable with only a keyboard you'll be nearly there anyway.

Any half-decent datepicker library is going to be accessible.

If you absolutely must reinvent the wheel, then yes, you will need to put in a bit of extra effort to make it accessible.

Yes, this.

I originally learned how to build accessible web sites and apps in 1996,when I interned at a startup. Most web standards make it easy to implement accessibility. It's generally only when building complex, custom stuff that it becomes harder, IMO. And (also IMO), that custom stuff tends to be fragile and break on other browsers or over time anyway, so I've avoided it ever since.

Right, but at what point does some of the burden of making a website accessible fall on the screen reader application used by those with disabilities? Like, if there's nothing technically preventing the screen reader from reading the website, it's just that the site does not do things the way the screen reader wants them to, why does the onus fall on the site owner?

I presumed screen readers had some kind of standard in the way they interpreted things. The standard allows the user to choose which screen reader they want.

Letting the screen readers interpret things however they want seems likely to end up in a situation like browsers. Horrible shims everywhere to handle the idiosyncracies of how each reader interprets things.

> Does my blog have to support accessibility? I don't sell anything, but it is public.

No, it doesn't. Your home also doesn't need to be wheelchair accessible, even if you throw a party and welcome anyone in.

> Is the neighborhood softball league going to have to implement it?

Sounds like a private club so no, it doesn't.

The outcome of this case would not change the answers to these questions.

> Commercial entities will probably have to comply

Yes.

The law in question applies to "places of public accommodation" which is a legal phrase. This case, and similar cases, hinges on one of two questions: 1) do the ADA obligations of physical places (like grocery stores) extend to their non-physical goods and services or 2) do websites, apps, etc. constitute "places" in their own right (e.g. does this particular law apply to Hulu, Tinder, etc.)?

In my opinion, the majority in this case was too focused on the laws lengthy, but clearly not comprehensive, list of example places, all of which were normally thought of as physical (but are not inherently so, even when the law was written), they didn't concern themselves enough that the clear intent of the law is to provide equal access to goods, services, etc.

> I suspect the Domino's ruling will be the winning one, but I don't know where that line gets drawn.

I'm not so sure. Keep in mind that ADA doesn't require that you provide everyone with the exact same way to do everything. For example, a taxi company doesn't have to equip every cab so that it can handle every disability that might be encountered. It is OK for them to only have part of their fleet equipped for various disabilities, and dispatch those when someone needs one.

With Domino's case, you have a lot of variations the customer has to choose from, and a lot of information that is on the website that would be slow and inconvenient to deal with by phone. Nutritional information, for example. It would be quite the hassle (for both the customer and the person at Domino's) to get nutritional information for all the options a customer might be interested in. I've spent 20 minutes at times fiddling with the build-your-own options checking out nutritional trade offs--that could have taken hours on the phone!

Domino's also usually has a ton of coupons available and a bunch of different specials. Dealing with all those over the phone would also take a lot of time.

Compare to a prescription refill at a pharmacy. There generally all you need to do is communicate your prescription number to the pharmacy. A phone refill consists of calling and when they answer saying "I need to refill prescription #NNNNNNNN".

I think it is quite possible that courts will ultimately agree that for ordering a prescription refill, at least at a pharmacy that hasn't gone overboard with coupons and deals, providing phone ordering is sufficient accommodation for blind people but for ordering pizza at a place with a large menu that has a lot of customization options phone ordering is insufficient accommodation.

Any store with a combinatorial explosion would probably have a hard time creating any serial interface. The phone is such an interface, but in some ways it’s also the best because it’s one that comes with a human.

Ordering a pizza usually isn't that complicated. I don't think my local place even has online ordering. I have a paper menu at home. I decide what I want, call them, and then I pick it up.

Absolutely every online pizza ordering system I've ever used has been more complicated and taken longer than the tried-and-true phone call system. Online menus are great. Online ordering is awful.

I love online ordering. I am exposed to the full options for customising a pizza so I can add and drop ingredients easily. I can also experiment with what coupons give me the better deal for the set of pizza I'm ordering. These two things are awkward when ordering in person or online. Also useful when you are collecting orders from several people. You can just add each persons order to the online cart without having to write it down and then repeat it all over again on the phone.

I can authenticate with a fingerprint and tap a "reorder" button while sitting at a red light. Definitely not awful. :)

Bit of a tangent, but is this how refills work? I thought you called your doctor, and they call or transmit the refill authorization to your pharmacy. I don't take any prescription meds that ever need refills so maybe I'm wrong on this? Seems weird that I would be able to just go to the Winn-Dixie website and say "I need a refill on my OxyContin"

When a doctor prescribes medication, they have the option to include a certain number of refills with the original prescription. This may not apply to all medications, but I don’t know the technical details.

You obtain your initial prescription from your doctor. It used to be that the doctor gave you this on paper, and you took it to a pharmacy to fill. Nowadays most doctors ask you what pharmacy you use and are able to transmit the prescription electronically to the pharmacy.

If this is expected to be an ongoing prescription, typically the doctor will authorize N refills. The pharmacy can fill those refills with no further interaction with the doctor.

Many even automate this. The pharmacy I use for most prescriptions send me a text message when I should be near running out, and I just have to text back "yes" to refill it.

When you are out of refills, the doctor has to authorize continuing the prescription. Most pharmacies will handle that for you. You ask the pharmacy for a refill, they tell you that none are left, and that they will contact your doctor on the next business day.

In older times that was usually by fax or even by making a voice call to the doctor's office, but nowadays I think it is mostly via some sort of computerized system.

It's not actually your doctor that has to authorize additional refills or reissue a new prescription. It is often a "physician's assistant" at your doctor's office that handles this, especially when it is just renewing an ongoing prescription. There are also some kinds of nurses that can processes refills (there are something like 20 different kinds of specialized nurses--I forget which ones can processes prescription refills).

From the patient's point of view, then, it looks like this:

1. You get a prescription for some ongoing condition from your doctor,

2. When you need a refill, you ask your pharmacy.

3. Every so often there is a day or two delay in filling a refill because the pharmacy has to get your doctor's office to renew the prescription.

Are people that are ordering pizzas from Dominio's really spending time deciding what toppings they want based on nutritional values provided by Dominio's? I would be shocked that 1 person decided against the pepperoni based on nutritional values.

I think there's a fair amount of information accessible through the website that would also be annoying to access over the phone. For one, I don't have any idea what my prescription numbers are. I would suspect that's true of the majority of people. You also have no way of knowing how many refills you have left, which could be annoying if you have several medications. My pharmacy also has a lot of options for mail delivery that are annoying to deal with by phone.

The plaintiff also mentioned privacy as one of the aspects he loses on when he goes in person. The phone solves that, but only if you're in a private place. I can order a refill from the app on my phone or their website basically anywhere, and no one around me knows.

I worked in the web accessibility space a decade ago.

It really wasn't hard back then.

However, for something as simple as a providing prescriptions, there is no argument that whatever was easy a decade ago won't work. They could either make a separate link/interface for accessibility purposes[0], or have done the right thing and designed it to be accessible from the get go, instead of trying to shoehorn an existing design into an accessible one. I'd bet money that the real problem here is that they built the site with little regard to accessibility, and are now dealing with the fallout. I'd wager that had they planned for an accessible site from the get-go, they would have built a site as good as it is now, and be accessible, with little extra cost.

[0] Frankly, some ordinary people like me might actually prefer the non-fancy accessible UI. I bet most of their non-accessible stuff has little benefit to me.

Isn't that the approach? I'm not much in front-end work these days. I thought it was:

1. Build a simple HTML/Forms implementation that works (but obviously is not feature-rich).

2. Enhance (1) with JavaScript/CSS to add all your fancy UI cosmetics. If there's no JavaScript or CSS, then you get the unenhanced version by default.

Clearly for some things (e.g. Maps) that are inherently visual this isn't possible, but for the typical customer/business transactions we are talking about here, seems to me it should work.

You're basically describing "progressive enhancement." People with disabilities aren't really more likely to load a site without JavaScript or CSS though, a site can still require JavaScript and CSS to operate. It does take at least a little more work to make a form work through POST and as AJAX-submitted JSON. To be accessible, a site should be robust enough to work even when everything isn't the same as when the web author uses it (users use keyboard and other inputs instead of a cursor, have different screen sizes, zoom or enlarge text, use Windows High Contrast Mode to replace the site's colors with their own choices, etc.).

> Clearly for some things (e.g. Maps) that are inherently visual this isn't possible

The first interactive online maps were static images with North, South, East, West arrows (links) to load the next image; having to load the whole web page again for the next part of the map is not nearly as nice as loading image tiles dynamically but it does work. Dyanamic tile loading also doesn't have to be done only by cursor or touch, you can still have on-screen arrows that can be tapped or keyboard operated to load more tiles (plus loading tiles based on keyboard arrow keys, WASD, etc. while the map is focused).

is that any different from saying that installing wheelchair ramps in old buildings will be expensive and, in some cases, difficult?

You can build a wheelchair ramp and perhaps it needs some new lumber occasionally but it's relatively easy to spot and fix problems.

For a website, it could easily fall out of accessibility with an update to some library you rely on, and you wouldn't even know.

To me, the difference is that software is never finished and behaves differently depending on who's using it on what OS and what web browser, and is thus that much harder to keep compliant.

That's only because there are no incentives to make libraries work (and keep working) wrt to accessibility.

So the courts provide the incentives.

What if a business is in a city and the building is old? The number of stores downtown with a single step is surprisingly high.

What are the rules on building the ramp on a public sidewalk?

The roadblock isn't always maintenance, it's doing the work up front to avoid that step being a problem later.

There are definitely edge cases where a ramp can be harder to build than an accessible website is to maintain over the long run. I'm unconvinced that's more than a tiny fraction of the overall problem space.

If you are using automated testing then you need to make the site accessible to the test script. Which kind of makes it accessible to screen readers automatically.

I feel like this attitude undermines the fact that web development is an industry with skilled workers. A well crafted web site is accessible by default. A skilled web developer knows which parts can be problematic and deals with it. This is really no different then a skilled carpenter know how to build a robust wheel chair ramp.

A bad contractor will have unskilled carpenters build unsound ADA compliance that requires expensive maintenance later. The same applies for web dev shops.

A grocery store is going to find it far easier to recognize shoddy workmanship in the physical world.

And, again, the only software that ever "finishes" is the software that falls into buggy disuse.

The same attributes that make the digital world much faster to create a solution than the analog world make it much more challenging to maintain over the long run, and more difficult to for most people to be able to tell the difference between good work and poor work.

I'm not saying we shouldn't expect the business world to be accessible online, just that I'm not convinced it's practical for smaller businesses. I think the end of that road is just forcing them all into Facebook's arms, which is the last place I want them to be.

> web development is an industry with skilled workers

It's an industry with some skilled workers but a lot that aren't. It's amazing to me, who watched the web develop as a non-professional, how many workers don't know basic things about HTML, CSS specificity, etc. That ignorance leads to the web being worse in many ways, not just less accessible.

I used to think that if you call yourself a "web professional" that part of that was understanding how to make things accessible, basically "it's your job, do your job;" if the so-called professionals did that then the problems of inaccessible sites would go away.

I do still think there are some fundamentals that every web professional should know and handling those takes care the large majority of barriers. I underestimated how vast the web profession is and the scope of possible accessibility problems and now think that even if web professionals become better educated, there will always be a need for specialists in accessibility (which is self-serving since I have become one).

Yes. This is actually an argument against -- what defines a "reasonable" accomodation includes what alternative solutions are available and the cost to implement. For instance, an alternative accommodation could be a member of store staff retrieving your items for you, instead of putting in a ramp, if the necessary ramp would violate sidewalk clearance.

It does seem to dance around the issue of how easy bridges are to build without major flaws compared to how hard similarly sized software applications are to build without major flaws. I would suggest that it is entirely possible the same reasons that we can't treat software projects like physical construction projects also applies to accessibility. I'm not saying that is the case, but that I haven't seen reason for it to not be the case and it should remain an option until shown otherwise.

> It does seem to dance around the issue of how easy bridges are to build without major flaws

ahaha what

https://en.wikipedia.org/wiki/List_of_bridge_failures#2000%E...

There are a lot of bridges in the world, so the list is relatively short. If your argument that bridges are as hard (or harder) to build safely compared to software at a similar scale, I don't think a list of bridge failures backs that argument without comparing it to total number of bridges and then doing similar comparisons between software failures and software.

I don’t think it is easier to build a safe bridge, we just make the effort to do it.

I think you're right. Unsafe bridges kill people. Most bad software does not, and when it might, we generally are more careful with it (not always, just as we still have bridge failures from time to time).

Implementing text and a form to POST is really simple - especially when you don’t have to style it, etc. Blind people don’t need flashy UI’s. They need text and HTML serves this well.

I don't see how all sites can comply nor do I think they should. However this really begs additional legislation to clarify the issue.

What we need to identify is essential goods and services and any retailer offering such needs to provide reasonable accommodation if the method of the offering makes it feasible. The issue with some handicaps is that within each there are levels of impact. So that needs to be considered.

With regards to the statement earlier where I think not all should be required I am just having mental block in understanding how would I communicate to a blind person a site like ebay where users put up goods and the vast majority rely on visual cues. Now the ordering and payment functions surely can be adopted but when you have user driven content what is a vendor to do?

So, back again to legislation so that the courts don't much it up so much it becomes a paradise for predatory lawyers.

I disagree. Getting to a basic level of accessibility (e.g. WCAG AA) is incredibly easy. Any public accommodation can easily afford it.

A blog is not a public accommodation, so it does not have any accessibility requirement.

I don't think that one size fits all. Maybe there should be different versions of a website to handle different needs.

I’ve been doing more accessible work and it’s a mess. Like oh you NEED to use JavaScript to make a pure css drop down menu accessible.

Instead of putting the burden on web devs to create hacks around screen readers, how about the consumption software get better? There’s no reason it can’t detect a :hover and treat that as a JavaScript event flipping an aria tag.

Don’t the principles of progressive enhancement solve this? Build your site so that it can be used without js, etc and enhance features when you can detect the user is capable.

Any type of menu should be able to display without scripting.

That’s exactly why I like using pure css when I can. Using JavaScript just to support aria tags is really backwards

That's a massive hack that also won't work on mobile. Don't try and make real websites with real consequences if they fail like that. Either write websites that don't have the pretense of being fancy and don't use javascript (ie, your menu is just an always visible list of links) or use some javascript.

Edit: I regret how rude this comment is.

Mobile has a flat menu, but thanks for assuming?

Please don't respond with swipes, even if another comment was provocative or you feel it was. There's good information in your comments, but curious conversation (which is the goal here) also depends on how people conduct themselves.

https://news.ycombinator.com/newsguidelines.html

Can you please argue a little more respectfully? Comments like this and leading with "Wrong" (https://news.ycombinator.com/item?id=26762908) have sharp elbows and evoke worse from others. There's good information in your comments, but curious conversation (which is the goal here) also depends on how people conduct themselves.

https://news.ycombinator.com/newsguidelines.html.

I apologize, thanks for correcting me.

Appreciated!

It was a blunt comment but I did not find it disrespectful. Sometimes it is necessary not to beat around the bush as non-disabled people tend to do when dealing with topics to do with disability or accessibility.

If you can display something on :hover, you can also display it on :focus (and/or :focus-within). Pure CSS dropdown is more of an issue for touchscreen use; touchscreen-only users are not limited to smaller mobile devices.

Please don't make a megamenu using CSS alone; for any keyboard-only user, sighted or blind, that's too many links to Tab through.

Reply on news.ycombinator.com