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.
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.
FWIW, I'm very sure third-party apps are already legal (and have always been legal): the issue was never that you aren't legally allowed to make them, it is merely that, once you do, the company making the product goes out of their way to break your client or ban your accounts; so, what you'd really need to do is to make it actively illegal for a company to prevent you from making a third-party app... even by any such technical means that they will absolutely defend as some form of "spam prevention" or "security mitigation" or "content restriction".
What I mean is get rid of any way that the legal system can be used to prevent third-party apps. TOSs, CFAA, DMCA, contracts, etc. should all be null-and-void when used to prevent interoperable third-party apps.
Companies with large market share should also be actively required to facilitate interoperability, e.g. with APIs available on FRAND terms.
I am very confident the DMCA already doesn't apply even if this were a copyright issue (which I don't think it is) due to interop exemptions, terms of service generally aren't legal issues in the first place, and the CFAA doesn't apply as there is case law that this is not "access". I maintain: there already is nothing stopping you from making a third party client except 1) how people keep making the stupid mistake of violating trademark law in their third party client (which is trivially avoided) and 2) the legal right of the service to refuse service to anyone... you need to make that actively illegal, and then defend that that makes sense against the onslaught of arguments that they need to be able to ban people due to spam prevention, security mitigation, and content restriction (and the EFF coming out of nowhere with some kind of argument that this is going to undermine the right of free speech of the company due to similar arguments as to Section 230, etc).
You would also need to mandate that they supply a reason for banning you that you can argue against. As it is now you could just get banned with no recourse or reason for using a 3rd party app on many platforms.
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.
The art of standard serverside generated HTML and progressive enhancement or a page composed of JavaScript apps/widgets for interactive elements seems lost today. In the age of React everything is a SPA first by design from observations.
Having previously worked and taking a great interest in the schematic web last decade, progressive enhancement, accessibility, page size, etc etc the modern web is disappointing when what should be a simple HTML website instead be a blank white screen while it downloads 2mb+ of assets then a SPA bootstrap to show something loading json blobs embedded in the page and leaking information with the insistence of doing everything client side.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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"
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.
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.
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.
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.
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.
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).
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.
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.
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.
> 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).
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.
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.
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.
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.
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 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’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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
You still need some sort of verification, even for something as simple as ensuring that images have alt-text. Maybe you missed some images that are dynamically generated in a way you forgot about, or have a typo in the tag.
If screen readers aren't compliant to the standard, then you need to test against as many screen readers as possible to ensure that your site is accessible. Users want a site that works, not a site that complies to an unimplemented standard.
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">).
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.
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.
That was part of one of my best techniques. The boss thought I was crazy when she caught me trying it, but I would put on very dark sunglasses, fire up the site in Lynx, and then use a pencil in my teeth to get around. If that was too hard, I knew I had to rethink something.
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.
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:
> 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.
> 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.
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.
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.
> 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.
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.
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).
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.
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.
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.
> 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.
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.
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.
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?
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.
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.
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.
"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.
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.
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.
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.
> 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.
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).
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.
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.
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).
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