What are reasonable accessibility changes to start with?

🙋 Questions
, ,
1

I’m noticing a lot of apps I’m auditing have little to zero WCAG conformance. I’d like to make useful suggestions on where we can improve, but I’m having a hard time not throwing the book at them.

For example almost none of the apps have proper labels or placeholder text. Anyone with a screen reader would get “text input” as the description for EVERY input on the page :man_facepalming:

When I suggest improvements (obviously I can’t throw the entire book), what’s a good/safe place to start? Is it things like labels? Are there other places that are better to start on?

5 Likes
2

I’m not the best person to answer, but I’d like answers, so I’m writing this answer in the hope it inspires some thoughts and perhaps more answers.

What is the goal? It depends if you’re making suggestions for the betterment of humanity or in service of compliance. It may depend on the kind of apps, and what they are for. If an important function relies on sound, for example, an alternative is a must.

The suggestions may not be about the app. If a bank brings out a new app and demands that everyone use it to save money on phone systems and email lines then it has to provide accessibility functionality that allows the main facets of banking - dealing with accounts, moving money, making payments, getting help, etc or provide them elsewhere. So if I shut down my phone line, which is an accessibility concern for people with visual impairment, in favour of my app, which has small text, then I’m in trouble. And so are the users.

If I provide communication between players in a game released in the US market then that falls under communication and is subject to the CVAA. There are quite clear guidelines about what your in-game communication should/has to be able to achieve. Rules and guidelines can come from unexpected places.

What are the most common disabilities of the users of those apps, and/or what changes would have the biggest impact among the most common disabilities? That is both helping the most people and avoiding the most lawsuits.

The things that you suggest might be influenced by local or international law. In the UK the EQA seems to base its wording on what is “reasonable” - in terms of the duty to service providers (websites are a service) and means as close to an experience that non-disabled people have as is reasonable. The courts decide on what is reasonable.

In the UK the duty to make reasonable adjustments to services to provide accessibility, in law, is ongoing. In that spirit it may be wise to take any advice and form a plan to give to people to make accessibility considerations with all design choices.

So I guess I’m saying that it depends.

4 Likes
3

I love the spirit of this. Thank you! :slight_smile:

What is the goal?

The betterment of humanity and users. It’s not compliance driven. I’m not aware of specific app users with specific disabilities, but I think we should at least have the basics in place so they can at least get around and do the main things.

To be clear, I’m not advocating for mediocrity, just something that’s incrementally better than nothing.

2 Likes
4

Then I’d leverage persuasive techniques, like compliance issues that put the business at risk from fines and lawsuits, or affordable changes that they can make quickly, or access to additional markets - accessibility may be so bad in an industry that having it be accessible makes it the top app for people with disabilities. Also accessibility features often are useful for people without disabilities - most people who use subtitles have no hearing loss at all.

What the wins are is going to be contextual and the rest I’m not experienced enough to advise, but I’m interested if anyone has anything at all to add.

2 Likes
5

In situations like that, I recommend addressing all the issues necessary to make the website or app accessible to one or more user groups. The starting point is often making it keyboard accessible, which would include (and this may not be an exhaustive list):

  • Ensuring that all interactive components receive focus.
  • Ensuring the focus order makes sense.
  • Ensuring that there are no keyboard traps. Also verify that modal dialogs really are modal - this is a keyboard trap, but of a permitted and expected type.
  • Ensuring the focused component has a clearly visible focus indicator.
  • Ensuring the focused component can be operated using the expected keyboard controls (not some weird interaction model the developer dreamed up).
  • Ensuring the focus remains on the component or moves to the expected location after the interaction is complete.

If any one of those requirements is not met, the app will not be keyboard accessible, so it’s important to fix them all.

Next you might decide to fix all the colour contrast and non-text contrast issues. Again, you need to fix them all, not just the easy ones. At this point you might decide to address other issues that affect people with low vision, which would include the Resize Text and Reflow success criteria.

Screen reader support may come some way down the priority list because it relies on all the keyboard accessibility issues being fixed first. Then it requires quite a few other success criteria to be fixed, such as Name, Role and Value, Status Messages, Info and Relationships, text alternatives for non-text content, etc… If you can’t fix all of these, it may be best not to fix any of them and to use your resources to fully support a different user group.

It may not seem fair to de-prioritise some user groups, but it’s the only sensible thing to do. There’s absolutely no point doing half the things that each user group needs. Pick one user group, fix everything they need, then move on to the next group.

Furthermore, publish your roadmap in your accessibility statement so everyone can see what you are planning and when. This shows you are doing something when it may appear you are not. And it may discourage law suits or provide a level of mitigation, especially since genuine law suits are incredibly rare. That said, if you’re in the US my advice would be entirely different due to the unique circumstances there.

1 Like
6

This makes a lot of sense. Esp going after the keyboard interactions first b/c without that it’s going to be REALLY hard for the screen reader folks to get around to begin with. :+1:

You mentioned the US being totally different. Could you expand on that? I’m in Canada and we get a lot of overflow from the US here. There definitely isn’t the level of care for accessibility that I’ve seen from UK based people, but maybe we can work on that :slight_smile:

7

When we’ve had reviews for accessibility these topics came from business departments (that were funding the IT development generally):

  • What changes are needed; What’s the priority for them?
  • How much does it cost to make them;
  • What kind of revenue increase are we expecting?
  • How will we manage the priority of accessibility changes that conflict with these X features that we want to have this year? Which one should we postpone?
    To understand the business, in this case, the backlog of requirements was about 4-5 years long.
    So the revenue trumps decision-making.

Probably useful suggestions can come once you understand the statistics of the users of the application and their patterns of behavior.

8

The perpetrators
The situation in the US is a complete tangent to this discussion, but here goes. As you may know, the US is plagued with ambulance chasing parasite lawyers who file spurious ADA claims against the websites of organisations with particular profiles in the expectation of a rapid pay-out.

The victims
The victim organisations are usually in one of a limited number of sectors, such as luxury goods retailers, restaurants, hotels, leisure and fashion retailers. They are large enough to be worth suing, but small enough (perhaps a turnover of no more than $200M) that they don’t have a large legal team who will drag things out forever. The perps want to get in and out quick.

The sting
The whole thing is a cynical cookie-cutter scam during which no disabled person has been involved, let alone experienced a barrier to service, although the lawyer may pay a disabled person to say they did.

The lawyer uses an automated testing tool, with WAVE being the tool of choice. If it finds any accessibility issues, the lawyer slaps the organisation with a boilerplate set of legal paperwork. Note that the paperwork is always identical. The issues the tool found may not be in the paperwork and vice versa.

When I raised this with a client who was being sued, they said their lawyers didn’t want to argue about technical intricacies in front of a judge and jury who don’t understand it. It just looks like you’re trying to weasel out of your responsibilities, which could make the eventual penalties even worse.

If things go to plan, the lawyer makes perhaps $20k to $50k for a couple of days’ work, and they might do a dozen of these every month. Sadly, this is possible because US law is a joke, and a bad one at that. In just about every other country, the equality laws require the plaintiff to notify the potential defendant of any accessibility issues and allow them time to fix them or provide the service by other means. But in the US, none of that is necessary - the first you know is when you get slapped with a law suit.

My advice
My advice to US clients is to first ensure that your website does not show any faults when tested with an automated testing tool. That means not just fixing the genuine issues, but doing whatever is necessary to eliminate the false positives. If the tool doesn’t find anything, the lawyer will just move on to the next victim.

I would even prioritise that over doing manual testing and fixing the real issues to improve the user experience. It might not sound like a nice approach, but if you do things in the wrong order you might end up paying a scumbag lawyer $50k instead of putting that money towards fixing things.

1 Like
9

Some great answers above particularly focusing on automated results in the US market. Personally I rank things by user impact, so anything to do with keyboard or contrast tends to be high on the list.

1 Like
10

I get what you’re saying, give revenue numbers to justify prioritizing this over X other feature, and do some research on the cost/impact. And I see how business decision makers would respond well to that.

I just have a really hard time with that way of thinking about accessibility that way. I see base-level accessibility as a “societal good” and way to delight customers, not something that you can put dollars on. And I would suspect the number of customers with accessibility needs represents a fairly small part of revenue.

11

Ug, that’s so unfortunate. I agree with your recommendation: just scan your site with WAVE (or similar) and fix everything it reports, even the false positives. Thank you!

12

While I agree with you, our way of thinking isn’t important if we’re not the decision makers. The only things that matter are their way of thinking and our ability to influence it.

I am fortunate that most of our clients are in the public sector, so revenue isn’t an issue. They typically have hard constraints on time and budget and are looking to benefit the most people within those constraints.

In a commercial enterprise where a product manager is personally responsible for profitability, it’s totally understandable if they take into account revenue and opportunity costs. They are not a charity and don’t have the luxury of forgoing profit for “societal good”. They have to balance a lot of things, including legal obligations and public relations risk, and ultimately they do have to put a dollar value on everything in order to make decisions.

1 Like
13

There are approx 1.2 billion people in the world living with disabilities and annually their spending power is approx 4 trillion dollars. That’s 15% of the global population and https://www.wethe15.org/ has more information. Not to mention people use screen readers for many more reasons than a lack of vision and people use a keyboard rather than a mouse for many reasons. Saying your customers with accessibility needs are small is a myth that has been disproven over and over again.
If your site is not accessible your revenue from that demographic will of course be 0%.

14

While that’s true, I think it’s really stretching matters to use figures like 15%, and I’ve seen figures as high as 20%. To get to those figures you’ve got to be including people with very mild conditions that have little or no effect on web browsing. I’m a strong advocate for accessibility, but it doesn’t help if we over-state our case.

It’s also worth bearing in mind that some organisations don’t want more sales if they are limited by their delivery capacity, so spending money to change their websites makes no sense. You’re not likely to get anywhere with those organisations.

1 Like
15

I have found a safe place to start with accessibility is something easy and understandable. Topics with objective right or wrong options are helpful for beginners (color contrast vs. logical order). If a tool will give you the answer even better. Screen Readers can scare people to the point of not doing any accessibility.
This might not be the ideal solution for users. I’m of the opinion better some accessibility than nothing. After you’re already doing it it is easier to tackle the more difficult stuff.

1 Like
16

I would definitely agree that something objectively right/wrong would be a helpful place to start. And I think there is definitely a momentum aspect to this, where if you start with a few easy wins, PMs/designers/developers are more aware of it and doing some of the deeper work becomes more natural.

Color contrast seems like a useful one. Basically point to the WCAG or Color and contrast accessibility  |  Articles  |  web.dev as the an objective pass/fail that designers and devs can use when developing.

Cool, thank you for the suggestion!

17

I wrote this article as a place for everyone to get started with accessibility testing so might be a good list to request changes?

1 Like