[HN Gopher] Court rules grocery store's inaccessible website isn...
___________________________________________________________________
Court rules grocery store's inaccessible website isn't an ADA
violation
Author : Tomte
Score : 108 points
Date : 2021-04-10 13:47 UTC (9 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| fcatus wrote:
| I'm not undermining the importance of this issue, but some
| details in THIS SPECIFIC STORY that doesn't add up. Since when
| you need to tell the pharmacist your order? You just say your
| name and they look it up on their system... Also, couldn't he
| contact the company about the issue before immediately filing a
| lawsuit? Sounds like he's looking for big cash.
| prpl wrote:
| Was there an option to cure the violation? I would think devs
| would have billed less than lawyers.
| temp8964 wrote:
| It's really hard to say which one costs more. If they fail or
| give up the law suit, then the challenge becomes open-ended. If
| they win the law suit, the cost is fixed.
| WindyLakeReturn wrote:
| I thought the ADA didn't allow a cure to stop a lawsuit. once
| in violation there is an injured person who now has to be made
| whole regardless of other actions you take. Wasn't this one of
| the main reasons the ADA led to some lawyers to go fishing for
| violations?
| extra88 wrote:
| Typically in disability lawsuits, the plaintiffs are seeking
| nothing more than the problem be corrected and coverage of
| their court costs, they don't seek damages.
|
| Unfortunately, in recent years, there's been a spate of
| lawsuit trolls primarily interested in a cash settlement and
| don't care if the problem is corrected or not. There are
| examples of this over both online and physical violations.
| underseacables wrote:
| I'm an ardent defender of the rights of the disabled, but I think
| this is a broad stretch. This feels more like greedy lawyers than
| an actual problem.
| kiwijamo wrote:
| As a disabled person I find your definition of ardent defender
| interesting. I think blind people have every right to expect
| they can do what signed people can do on the web when it comes
| to accessing health services such as the one described. It
| would not take too much work either to make it accessible from
| the sounds of it either.
| tpmx wrote:
| > Gill also preferred to order prescriptions online because it
| offered greater privacy. In court, he testified that ordering in
| person as a blind man made him "uncomfortable because he did not
| know who else was nearby listening" as he told the pharmacist his
| order.
|
| A pragmatic solution might be to offer people like Gill to phone
| in their prescriptions.
| throwaway_kufu wrote:
| Im supposing that way he can be certain others are listening,
| but he would still be in the same boat of not knowing exactly
| who was listening.
| tpmx wrote:
| Just like non-blind people won't be sure which people see the
| combination of name + medication before they pick them up.
|
| > A few years ago, Gil learned that the store offered
| customers the ability to fill prescriptions online. Ordering
| online saves customers time because prescriptions are ready
| when the customer arrives.
|
| That implies that a person read the order and prepared it for
| pickup.
| kiwijamo wrote:
| I think his concern is not about employees (who are
| required to be ethical) but random members of the public
| who could use the information they learn in malicious ways.
| tpmx wrote:
| I can only assume you didn't read my first comment about
| using the phone to specify the order.
| shariqm wrote:
| I see some people are feeling conflicted trying to balance 1)
| Making the web more accessible with 2) Increasing
| business/startup costs.
|
| It's important to remember making websites more accessible often
| benefits everyone in some way. e.g. providing an alt text
| description for images on your website obviously benefits
| visually impaired users, but it also benefits people who can't
| afford high bandwidth or people who are moving through a remote
| area. In the Microsoft framework these three scenarios are
| called:
|
| 1) Permanent (Visually Impaired)
|
| 2) Temporary (Can't afford high bandwidth)
|
| 3) Situational (In a remote area)
|
| There's good online resources for understanding these concepts
| [1,2,3].
|
| Anyway, for companies as big as WinnDixie, with $10B in annual
| revenue, they should be designing their websites to be accessible
| by everyone. For small businesses it would be nice if website
| building providers like SquareSpace and Wix made this as easy as
| possible for their users.
|
| [1] https://www.iweb.co.uk/2016/10/inclusive-design-why-our-
| webs...
|
| [2] https://www.youtube.com/watch?v=TAzkrXTGEOM&t=55s
|
| [3] https://www.w3.org/standards/webdesign/accessibility
| miki123211 wrote:
| As a blind person, I think that accessibility matters most in
| situations where there's little competition and/or high
| switching costs.
|
| A startup building a new email client shouldn't be required to
| implement accessibility, certainly not from the start. There
| are enough accessible solutions in that space, and while
| accessibility would be nice, it would make the barriers of
| entry much higher.
|
| On the other hand, Facebook, a company famous for prosecuting
| app developers for (mis)using their API, should absolutely be
| required to do so. If all your friends are on Facebook, you're
| not even allowed to build a more accessible Facebook client.
|
| I also believe that we should legalize 3rd party apps if the
| original app is inaccessible, regardless of the TOS or presence
| of DRM.
| TheCoelacanth wrote:
| I believe that we should legalize 3rd party apps full stop.
| The legal system should never be possible to use to enforce
| lack of interoperability.
| yjftsjthsd-h wrote:
| I don't think that's a solution; sure, making the site more
| accessible makes you reach more users even beyond the
| "disability" angle, but that doesn't make it a winning cost-
| benefit tradeoff immediately if ever.
|
| EDIT: By analogy, it's very like software portability. If you
| make your software support Windows and MacOS and assorted Linux
| distros and the major BSDs and Haiku, you'll get more users.
| But if you only target Windows you'll get 80% of the market,
| and Windows+MacOS will get you 90%, and after that you really
| need to think about whether it's a good investment to target
| more platforms. By all means, be accessible because it's the
| right thing to do or legally required, but it's not obvious
| that it's a sound business move.
| LeifCarrotson wrote:
| The reason the ADA exists is that it's almost never a
| profitable cost-benefit tradeoff to accommodate people with
| disabilities.
|
| But I'd much rather work at a company that was 1% less
| profitable or live in a society that was 1% less wealthy and
| accommodated people with disabilities than one that left them
| in the gutter.
| bobthepanda wrote:
| Well, it's easy to comply with ADA cheaply if you do it
| right the first time but a pain in the ass to retrofit
| things later.
|
| At least with webdev the problem is most people stumble
| into it and are not formally taught much about webdev
| specifically if at all. My undergrad never taught me a
| single thing about webdev practice. It's not like, say,
| architecture, where you not complying with accessibility
| regulations will be taught formally, or later when you
| actually implement it some code compliance inspector is
| going to deny you a permit to build. It really is the wild
| west in webdev still.
| yjftsjthsd-h wrote:
| I was specifically responding to a comment that said
| accessibility wasn't expensive because it lets you reach
| more people (or at least that was my reading of it). Yes,
| by all means be accessible because it's the right thing to
| do - I object only to the idea that we should do it because
| it makes sense from a pure money perspective. It's a good
| thing, that's just not the reason.
| shariqm wrote:
| I agree it's still not going to win the cost-benefit tradeoff
| in most markets. OTOH - I imagine making your software
| support more OSs is much more expensive than designing your
| website to be more accessible, at most $1M/year. If you've
| got billions in annual revenue that's pennies in the bucket.
|
| In my view, it's about trying to provide more 'equal
| opportunity' in this world where it's financially feasible.
| This seems like a case where it is more often that not.
| Again, for medium+ businesses.
| cmeacham98 wrote:
| > I see some people are feeling conflicted trying to balance 1)
| Making the web more accessible with 2) Increasing
| business/startup costs.
|
| Doesn't the ADA already have some exemption for startup/small
| businesses where it doesn't apply if you have less than X
| employees?
| matwood wrote:
| Even if the ADA does have carve outs, if a small business
| wants to do business with any government/public entity they
| most likely will have to meet some level of accessibility. A
| VPAT[1] is commonly asked for in these cases.
|
| [1] https://en.wikipedia.org/wiki/Voluntary_Product_Accessibi
| lit...
| gnicholas wrote:
| It appears that the exemption noted by others for businesses
| with fewer than 15 employees only relates to the obligation
| to accommodate _employees_ , not customers. [1]
|
| For example, one of the links provided elsewhere is to an
| EEOC website. The EEOC is the Equal Employment Opportunity
| Commission, which only relates to employment, not to
| accommodating customers.
|
| 1: https://www.accessibility.com/blog/do-small-businesses-
| with-...
| iudqnolq wrote:
| Less than 15
|
| https://www.searchenginejournal.com/website-accessibility-
| la...
| shariqm wrote:
| Ah yeah it does say that here:
| https://www.eeoc.gov/laws/guidance/ada-primer-small-business
|
| Good to know
| swiley wrote:
| Also, making webpages inaccessible usually takes work.
| Reasonable use of semantic HTML, styling, and alt tags for
| images are probably good enough. It's when you start doing
| ridiculous things with SPA frameworks (something no asked for
| or wants) that this gets hard.
| robertoandred wrote:
| SPA frameworks don't make accessibility any harder.
| extra88 wrote:
| I disagree. Even if an SPA framework (or more likely a
| library add-on) does a good job of reinventing the wheels
| of traditional HTML requests (e.g. announcing the name of
| the new "page" when it loads and setting focus), there are
| always going to be more details that will be at least a
| little harder to implement on each site.
|
| I'm not fundamentally opposed to JavaScript frameworks,
| even when used to make SPAs. I think their downsides can be
| worth using them anyway and issues like accessibility can
| be overcome. They are a paradigm that are chosen too often
| without enough thought about the downsides and are a bad
| choice as default.
| matwood wrote:
| Basic accessibility is nearly 'free' if someone uses modern web
| standards, and runs a tool to check during development. Things
| like alt tags, proper html tag usage, keyboard navigation
| (logical and without traps), and good contrast are good
| programming/design and good for every user.
| extra88 wrote:
| I agree that following web standards gets you a lot in terms
| of accessibility and is a part of good programming and
| design.
|
| There's a lot that automated checkers don't find. They can
| detect if an image lacks an alt attribute, they can't tell if
| an alt attribute's value is bad. Many are pretty good at at
| least flagging where there _might_ be a color contrast
| problem for a human to double-check. They don 't
| automatically find interactive components that aren't
| keyboard navigable or operable. They don't know when the DOM
| order of content doesn't make sense.
| matwood wrote:
| Sure, no tool is perfect.
|
| For me though, making sure keyboard navigation works
| properly early on _speeds_ up the develop and test cycle. I
| also think that in many cases, perfect ends up the enemy of
| the good. It 's a different conversation if a disabled
| person contacts someone about a site with a suggestion for
| improvement rather than it doesn't work at a all.
| Wowfunhappy wrote:
| For the web, screen readers are easy, the only thing I find
| problematic are some of the color contrast requirements.
| There have been several instances where we've had to make
| designs definitively worse in order to accomodate those.
|
| I somewhat question the need, as well--at some of the
| contrast levels we're talking about, if your vision is that
| bad, you should really consider enabling a magnifier, color
| filter, or even a screen reader.
|
| What becomes really problematic, however, are PDFs, which are
| _supposed_ to be a quick way to offer printed documents
| digitally, without too much extra work. Making those work
| with screen readers can take a long time, and there have been
| some cases where clients decided to just remove them from
| their websites. I 'm not sure what to do about that, but I'm
| concerned we're creating barriers to sharing information,
| with anybody.
| KeepFlying wrote:
| Totally. Especially if you design correctly from the start.
| Adding accessibility to a site/app/etc that was designed for
| years without it in mind is a pain in the ASS, but doing it
| from the start is simple.
|
| The contrast issues sometimes make design a bit harder, but
| it's totally worth it I believe.
| tyingq wrote:
| There are some spaces where websites are already mandated to be
| accessible via other regulations. Like airline websites...they
| are mandated via the Air Carrier Accessibility Act. You could
| look into how that progression went to see what a broader
| regulation would do. Though I suppose it wouldn't give much of a
| view into smaller businesses.
| BeetleB wrote:
| IIRC, any entity getting federal money (grants, etc) are
| obligated to make their web sites accessible.
| [deleted]
| tyingq wrote:
| Ah, okay. The ACAA website requirements happened in late
| 2015.
| iudqnolq wrote:
| Wrong, most websites in the US are currently required to be
| accessible. The ruling described by TFA overturns that in one
| region.
|
| https://www.searchenginejournal.com/website-accessibility-la...
|
| Edit: I regret how rude this comment is. It is also wrong, I
| misunderstood what happened.
| tyingq wrote:
| "Wrong"? I'm suggesting it's a space you could look at to see
| how the transition went, in a space where the website owners
| knew for sure it was required.
| iudqnolq wrote:
| And I'm saying it was always required, there was no
| transition.
| tyingq wrote:
| You don't see the value of studying what happened in a
| space where the owners of the sites finally agreed it was
| required?
|
| For sure, there was a burst of activity and change on the
| part of the airlines when this happened.
| tyingq wrote:
| _I regret_
|
| No worries. Sounds like you read some intent on my part to
| mean accessibility was optional. I wasn't trying to say that.
| gnicholas wrote:
| Not that everything is political, but it appears that the two
| judges in the majority were appointed by Republicans and the
| dissenter was appointed by a Democrat. If they end up having an
| _en banc_ hearing, the composition of the full Eleventh Circuit
| (excluding senior status judges) is seven Republican appointees
| and five Democrat appointees. There are also more Republican
| appointees among the senior status judges.
|
| Of course, this decision shouldn't be over-politicized; I only
| mention this because it is a relevant consideration in predicting
| the likelihood of an _en banc_ rehearing, and the possible
| outcome.
|
| My sense (as a former lawyer) is that _en banc_ rehearings are
| somewhat more likely when the majority of the judges would vote
| to reverse. Given the composition of the Eleventh Circuit, this
| theory would predict that there wouldn 't be a rehearing, which
| would leave this to SCOTUS to resolve.
| supernova87a wrote:
| I'm surprised that this is still getting litigated and having
| lengthy trials or opinions.
|
| You might remember that way back in *2002* this very same
| question came up regarding Southwest Airlines's website, and it
| was ruled that it was not a physical place covered by the ADA.
| https://en.wikipedia.org/wiki/Access_Now,_Inc._v._Southwest_....
|
| I think what it speaks to most is that Congress needs to address
| the question once and for all to not have this issue decided over
| and over by the courts.
| [deleted]
| tzs wrote:
| Here's your link in a form that gets through HN's formatting:
|
| https://en.wikipedia.org/wiki/Access_Now,_Inc._v._Southwest_...
|
| The last character of links ending in "." often gets eaten by
| HN. Writing it as %2e makes it work.
| supernova87a wrote:
| ah, thank you!
| sumnole wrote:
| Design should be accessible by default and progressively
| enhanced/gracefully degraded. Don't write off accessibility as
| something too hard to implement; don't perpetuate the
| underserving of the disabled and don't lose out on customers able
| or not that value accessibility. It's actually pretty simple.
| Here are a few resources:
|
| https://www.wuhcag.com/wcag-checklist/
|
| https://medium.com/@koalamango/web-accessibility-its-easier-...
| turnerc wrote:
| > Don't write off accessibility as something too hard to
| implement
|
| For a lot of these websites it would necessitate a lot of
| manual work, the unfortunate reality is that although producing
| accessibility features is not 'hard' it can be time consuming
| and most corporates won't go for it.
| Rule35 wrote:
| > For a lot of these websites it would necessitate a lot of
| manual work
|
| Yes, but ... That's work they brought on themselves by not
| doing the right things in the easy way. Sure, once they're
| there, there is a lot of work to come back but that should be
| used as a reason to not use those frameworks in the first
| place.
|
| Some accessibility is like adding alt-text. It adds work. But
| almost everything else is just not abusing the browser and is
| generally done simply by following the recommendations. And
| not trying to live on the bleeding edge.
| modularform123 wrote:
| Great ruling. These professionals plaintiffs can pound sand as
| far as I'm concerned. It's like this Yaniv character who goes
| around dressed like a woman to find someone unwilling to wax his
| balls.
| curryst wrote:
| 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.
| pasquinelli wrote:
| is that any different from saying that installing wheelchair
| ramps in old buildings will be expensive and, in some cases,
| difficult?
| macintux wrote:
| 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.
| runarberg wrote:
| 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.
| extra88 wrote:
| > 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).
| macintux wrote:
| 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.
| Tomte wrote:
| That's only because there are no incentives to make
| libraries work (and keep working) wrt to accessibility.
|
| So the courts provide the incentives.
| Forge36 wrote:
| 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.
| macintux wrote:
| 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.
| derekp7 wrote:
| 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.
| freeone3000 wrote:
| 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.
| WindyLakeReturn wrote:
| 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.
| jcelerier wrote:
| > 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...
| cortesoft wrote:
| I don't think it is easier to build a safe bridge, we just
| make the effort to do it.
| throwawayboise wrote:
| 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).
| iudqnolq wrote:
| 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.
| blincoln wrote:
| 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.
| blacktriangle wrote:
| 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.
| iudqnolq wrote:
| 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.
| TheCoelacanth wrote:
| 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.
| extra88 wrote:
| > 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.
| nemo44x wrote:
| 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.
| BeetleB wrote:
| 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.
| throwawayboise wrote:
| 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.
| extra88 wrote:
| 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).
| Shivetya wrote:
| 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.
| TheCoelacanth wrote:
| 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.
| dawnerd wrote:
| 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.
| extra88 wrote:
| 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.
| nemo44x wrote:
| 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.
| dawnerd wrote:
| That's exactly why I like using pure css when I can. Using
| JavaScript just to support aria tags is really backwards
| iudqnolq wrote:
| 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.
| dawnerd wrote:
| Mobile has a flat menu, but thanks for assuming?
| dang wrote:
| 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
| dang wrote:
| 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.
| iudqnolq wrote:
| I apologize, thanks for correcting me.
| dang wrote:
| Appreciated!
| kiwijamo wrote:
| 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.
| tzs wrote:
| > 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.
| dylan604 wrote:
| 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.
| threatofrain wrote:
| 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.
| ghaff wrote:
| 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.
| throwawayboise wrote:
| 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.
| kiwijamo wrote:
| 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.
| throwawayboise wrote:
| 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"
| lotsofpulp wrote:
| 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.
| tzs wrote:
| 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.
| jdavis703 wrote:
| If your service is still online-only (say you're an e-commerce
| retailer), then it seems one still has to make the site
| accessible.
|
| > And while filling a prescription in person might not be as
| private or convenient as placing an order online, the judges
| argued that it was good enough to satisfy the ADA.
| w-j-w wrote:
| I wonder if this will go to the Supreme Court? Given that
| different appeals courts disagree on the issue, it seems likely
| to me.
| tareqak wrote:
| From the last paragraph of the article
|
| > The Supreme Court reviews only a fraction of the rulings made
| by lower courts. However, the high court uses circuit splits as
| an important signal of which cases are worth taking. So the
| fact that the Ninth and Eleventh Circuit disagree makes it
| somewhat more likely that the high court will intervene.
| ghaff wrote:
| And there have been some other cases too in addition to the
| circuit conflict. For example, the DOJ told Berkeley it
| couldn't have videos online that weren't closed captioned.
| https://www.adatitleiii.com/2017/03/uc-berkley-to-remove-mor...
| racingmars wrote:
| We may eventually get there, but I think the article presenting
| this ruling as furthering a split-circuit situation is
| overplaying it. The ruling itself specifically addresses the
| 9th Circuit Dominoes ruling, and how the facts of the case are
| different. They don't see it as being in conflict, and they
| didn't say that they wouldn't have ruled the same was as the
| 9th Circuit if the facts were more similiar -- that is, if the
| web site functionality in question was much more critical to
| the core business (e.g. the way the vast majority of people
| order pizza from Dominoes).
| diebeforei485 wrote:
| This is the right decision. Otherwise we'll end up with Berkeley-
| style results where things are removed from websites because they
| aren't accessible enough.
|
| If this was primarily a delivery service (think Instacart), I
| would probably be on the other side of this. But it's clear that
| these are physical stores, and the online refilling is clearly a
| minor enhancement that only saves a little time.
| sevencolors wrote:
| I wish the government would make some guidelines on what
| accessibility means for websites. And what types of service need
| it.
|
| Some of my past clients that have a marketing website for their
| physical store. But now they are getting emails from scummy
| lawyers trying to extort money from them for failing to be ADA
| compliant.
|
| The changes are trivial for me but many people are forced to pay
| these lawyers to have someone "fix" the problem for them.
| throwawayboise wrote:
| IANAL but I would be surprised if a marketing website really
| fell under the ADA. It would be like saying a billboard or
| newspaper ad also had to be distributed in braille.
|
| If the website provides an actual service or business
| transaction capability to the public, I think that is where the
| ADA starts to apply.
| extra88 wrote:
| > billboard or newspaper ad also had to be distributed in
| braille.
|
| The law doesn't require fundamentally altering a product and
| it doesn't require unreasonable accommodations. The
| difference between an accessible and inaccessible website in
| terms of cost and effort, especially when set as an up-front
| expectation, is much smaller.
|
| A marketing website exists to serve some purpose, what
| purpose could there be that would only be relevant to people
| who don't have disabilities? That doesn't mean everything on
| a site has to be accessible to everyone, there can be
| inaccessible "fluff" meant to make customers feel good about
| a brand while still allowing all users perform the important
| tasks like reading information about upcoming sales, details
| about products, contact information, etc. No one's going to
| sue over a glamour shot having bad or not alt text.
| gnicholas wrote:
| Not holding my breath on this. The new White House website has
| been lauded by accessibility professionals for having
| accessibility features -- but when I took a look I immediately
| saw that their high contrast mode actually creates contrast
| issues (when filling in a form, the red error text is very
| difficult to read on a black background), even for fully-
| sighted users.
|
| It's also bizarre that they refer to this mode as a high-
| contrast mode, since overall it doesn't really offer higher
| contrast ratios; it's really much more of a night mode (as the
| icon seems to indicate).
|
| Also, their Accessibility Statement only lists phone numbers
| for how to give feedback. When you call one of those numbers,
| they ask if you want to leave a message for the President. When
| you tell them why you're calling, they tell you to use the
| general feedback form on the White House website (which is not
| mentioned/linked on the Accessibility Statement page. The last
| thing you want to do when collecting accessibility feedback is
| put a convoluted path like this in front of the user. Nearly
| everyone will just give up.
|
| TLDR: the government can't even get this right on its own
| websites.
| Rule35 wrote:
| Leave a message for the president explaining that his
| website's instructions are broken (and that it's literally
| easier to contact him than a webmaster).
| Causality1 wrote:
| I don't get this part: _" uncomfortable because he did not know
| who else was nearby listening" as he told the pharmacist his
| order._
|
| I've never once told a pharmacist my order. I walk up to the
| drop-off, hand them my prescriptions, and walk away. You don't
| even have to say "hello" if you don't want to. When it's ready
| they tell you the total and hand you a bag with your medicine in
| it.
| gnicholas wrote:
| That's true for dropping off prescriptions, but for pickup it's
| more complicated. First, a blind customer would want to confirm
| that he's getting the right medication, since he wouldn't be
| able to read the label or receipt. Also, blind customers are
| more likely to want the pharmacist to give oral instructions,
| for the same reason. This could be sensitive if others are
| nearby, since it's revealing private medical condition.
| Causality1 wrote:
| How would making the website more accessible have any impact
| on those things?
| gnicholas wrote:
| If the app/website can provide this information, the
| customer can listen to it in the privacy of his own home,
| instead of requiring him to ask in the store. Though I
| suppose he could also call the pharmacy and ask for the
| info. This isn't as convenient though (I'm often on hold
| for long periods when I call my pharmacy).
| imglorp wrote:
| I might be alone in this opinion, but it seems the abandoned
| Semantic Web would have helped here had we all adopted it.
|
| Commoditized API stories such as "order groceries" or "refill
| prescription" or "book a flight" would have a semantic level
| interaction instead of pixel one. Your user agent could act on
| your behalf through that API.
|
| With that in place, flashy UI sites can be built on top of the
| same API and kill several avians with one rock.
| at_a_remove wrote:
| Many years ago, I spent a lot of time in the doghouse during a
| major redesign overhall. I had no say over the design, but the
| HTML and CSS were up to me. I took as much care as I could to
| work on accessibility, despite all of the "hurry hurry hurry."
| The guidelines then were not especially helpful, but what made
| things particularly difficult was that I could get _zero_ access
| to any of the popular screen-readers.
|
| I like to think I did alright, and I was eventually told by the
| various disability groups that I did ... but I really, really
| think not having various screen-readers to test against was
| something of a handicap of its own.
| iudqnolq wrote:
| This is now a little better. One of the major screen readers is
| open source (NVDA, it's written in python and on GitHub), and
| there's a super basic one Google built for chrome you can
| easily try out.
| throwawayboise wrote:
| If the website is usable in lynx/links/w3m etc. then it is
| probably adequate as far as accessibility is concerned. Or so
| I've been told.
| ghusbands wrote:
| That's not really accurate, as screen readers read the page
| that's present in the modern browser (IE, Chrome, Firefox),
| including whatever has been done with JS (mostly), so even if
| the initial page is fine, your progressive enhancements may
| yet make things inaccessible.
|
| A very common problem is assuming mouse-only input for
| buttons or menus, making them not work from the keyboard use.
| neon_electro wrote:
| If you have a Mac, you should be able to use Voiceover:
| https://support.apple.com/guide/voiceover/welcome/mac
| extra88 wrote:
| Thank you for being a conscientious practitioner of your craft.
| BeetleB wrote:
| The point of having accessibility standards is that if you
| follow them, you won't need a screen reader to test them out.
|
| That this approach doesn't work is a sign that various vendors
| (including those who write screen readers) don't value those
| standards.
|
| I once worked for a nonprofit group that advocated for blind
| people - they were involved with the standards. This was a
| frequent complaint: Google/Mozilla were sometimes the problem
| as they felt some of the pretty good proposals would hamper the
| evolution of the web, etc.
| daveFNbuck wrote:
| It's hard to know whether you've followed the standard
| correctly if you can't verify the output.
| BeetleB wrote:
| > It's hard to know whether you've followed the standard
| correctly if you can't verify the output.
|
| Being able to verify certainly makes it _easier_ , but a
| standard like "Ensure all images have alt-text" does not
| require a screen reader to verify.
|
| And the thing with standards is that often no existing
| product (screen readers in this case) will fully comply
| with the standard - so if a given screen reader fails on
| your site, it may well not be your site's problem. This was
| (and perhaps still is) the case with Web standards in
| general. In the old days, there was usually not a single
| web browser that was fully compliant.
| zamadatix wrote:
| Your reasoning for why one shouldn't want to test with
| screen readers seems more like reasoning one should want
| to. The more divergence from standards the more you want
| to validate it works as desired not the other way around.
| extra88 wrote:
| I don't know how many additions are needed to standards but
| I'd like to see better support of the standards we have. It's
| way too common for browsers to implement standards wrong when
| building the accessibility tree. Also, there's so much of
| existing standards that are not supported by assistive
| technologies. I don't mean newer ARIA attributes, I'm talking
| about HTML4 (or older). Examples:
|
| 1. There's hardly any support by screen readers of the
| `headers` attribute on table cells, to associate the correct
| row and column headers.
|
| 2. Dragon NaturallySpeaking has provided voice control of
| computers, including web browsing, for quite a while but it
| still can't identify an implicit form input label (that is,
| <label>Name <input name="name"></label> rather than explicit
| <label for="name">Name</label> <input name="name"
| id="name">).
| gostsamo wrote:
| Currently the situation with screen readers is a bit better:
|
| * linux: orca, free and open source
|
| * windows: nvda (free and open source), narrator (builtin,
| free)
|
| * mac: voice over (builtin, free)
| [deleted]
___________________________________________________________________
(page generated 2021-04-10 23:01 UTC)