Accessibility: About People/Roles/Emotions.
Image source:http://www.cs.stedwards.edu/
Over the years, I have gotten accustomed to hearing a few phrases often repeated, a set of questions often asked while discussing accessibility. I am not going to (or am going to try not to) judge them but just try to organize my thoughts around why these questions crop up persistently. I also want to view accessibility from different perspectives to see if I can gain a better understanding of the forces that motivate us to do what we do. First, the catch-phrases:
Isn't it enough if we...?
This question is usually asked by a developer when he encounters a non-trivial code fix for an accessibility (a11y) issue or one that needs to be tested in different ways to ensure that it is really fixed (i,e testing with keyboard only navigation, screen readers, high contrast mode). This might be a developer who is meeting an a11y bug for the first time or someone who is in a time crunch to wrap up the last few #mustfix bugs before a release. This question could also come from a release manager who is trying to get rid of those last few issues before he can ok a product for release.
And usually the answer to this question is no, if you ask an accessibility analyst or an accessibility tester or a blind person using the application. The answer is a yes if you ask the manager who is responsible for getting the product out in time and the answer is maybe if you ask other parties involved in between. Some of these people are forced to choose the answer they choose because of the constraints under which they operate.
I have heard a yes for this question and a no and have personally felt the pull to answer either way depending on what I was doing then -- staying up late on a weekend night to wrap up a mustfix bug or making a list of a11y issues to make sure it is accessible to everyone in the real sense of the phrase. Like my boss used to say, the answer sometimes is just, 'It depends'.
Is it necessary to make this accessible given that...?
This question is usually an accessibility vs usability related questions. Let's take an example here. Say, you have a widget that has 5-10 little sections to it through which the user has to tab to eventually get out of it. Do the multiple tabs make the widget inaccessible? No. What if we make that 15-20 little sections to that widget, a user would then have to tab 20 times to get out of the widget? Is it accessible now? You see my point?
I have heard developers claim that the above mentioned widget is accessible because well, keyboard users can tab through it, screen readers can announce the section that has focus...and that's all there is to it.
But, what about usability for disabled users or even a sighted user who is prone to using a keyboard? I would hardly call this widget usable in that case. So, is it an a11y mustfix bug to allow arrow key navigation through the widget sections, so the widget itself is only one tab stop? Again, not an easy question to answer. The answer depends on whom you ask the question.
Do we have to cover all these cases...?
This usually is from a developer, manager who has just realized that accessibility testing is not just about screen reader users. There are several tools we can use and several use-cases we can run through to make sure a product is accessible to people who fall under any of the disability categories most relevant to the web: visual, hearing, motor and cognitive and not just blind people.
And yes, if you ask me as an accessibility specialist, my answer is yes, ideally, a product has to cater to all people irrespective of their abilities. But, I am also a developer and I understand what constitutes a risky change a week before a product ships which leads us to, 'Why are we making this risky code change for accessibility so late in the game?' which leads us to, 'Why did we not consider accessibility from the beginning i,e the requirements gathering and design phase?' and so on. One can even continue this trail all the way up to, 'Why are there no laws necessitating this to be accessible?'
I think a strong business case drives how important accessibility is to a company (at least in my experience). As a company, why is a11y important to you? Are you filing for compliance? Are you trying to win a major client who is interested in accessibility or has stringent guidelines determining whom they can hire/employ? Are you a champion for accessibility and have made a name for yourself in that space? Are you doing it because it is the right thing to do?
Usually, the answer is rarely the last question in this list not because companies don't want to do the right thing but because money/time-constraints/business reasons drive resources and how much time you can afford to spend on the reasons you want to spend resources and time on.
Usually, this concern is expressed by an engineer or by QA. Sometimes, people are daunted by the prospect of installing, learning and testing with a screen reader. Yes, screen reader testing is the best way to do accessibility testing for blind users but often, testing just with your keyboard will uncover a whole range of issues that eventually manifest themselves as a screen reader bug. There are a lot of browser plugins that a developer could use to say turn off images and show alt text instead or show the heading structure in a page if you don't have the time to test with a screen reader (although if you are on a mac, it's not that much of an extra step to turn on voice over and do a quick test).
Questions/Suggestions from management range from:
Why is all this coming up only now?
Typically, this is asked towards the end of the release cycle, usually the last few cycles of testing that are reserved exclusively for a11y testing. The solution to this is a no-brainer, the cost of remediating a11y bugs increases as you near the end of the software development cycle. The sooner you start keeping track of accessibility/integrating accessibility, the better for everyone but as we discussed earlier, this is not always as easy as it sounds on paper.
We are adding this new feature now, we can look into a11y for the next point release because...
The familiar 'features vs a11y' battle. There is a mini-feature that product management thinks will make the product that much better if introduced the last minute but the same resources are needed to fix much needed a11y bugs, also at the last minute. Which camp wins? Or another similar story goes: a feature bug fix needs to get in vs an a11y bug fix -- limited resource, time crunch, who wins? All of these are hard questions to answer and depending on the company's commitment to accessibility, have different answers. Usually if the feature bug fix gets in, it is at the expense of an a11y enhancement and really, who is to judge if that was a right call?
Please remove the 'must fix' tag from this bug because...
This is an ironic situation. The typical scenario is there is a dedicated a11y team within a company (Yay!) and they have been meticulously tracking and filing a11y bugs. Some of these bugs are fairly serious in nature and have been marked as #a11ymustfix. But, in the real world, #a11ymustfix != #mustfix bugs. These accessibility mustfix bugs are evaluated against stop-shipping bugs from all categories and then it might get demoted to a wish-list bug or a low priority bug. If not communicated correctly (and this is a ripe area for failure to communicate), the a11y team often realizes after the product releases that their mustfix bug has not been fixed and is now just a poor wish-list bug!
We can't plan for a11y from the beginning because requirements/features keep changing...
The argument I hear is usually, 'We don't even know if this feature will make it into the product, what is the use considering a11y for this feature?' The problem is, requirements at the beginning of a product cycle are fairly nebulous and in a way, this argument can be applied to anything thereby effectively preventing a11y from being a consideration at all early on in the product development cycle -- not a good thing.
We are too small to even consider a11y/an a11y team at this point...
This again boils down to business cause and priorities -- I heard this when I applied several years back to a startup I found interesting and they emailed back with this response.
Now, if you look at this whole field from a disgruntled user's point of view, someone who is excited about using technology and wants to complete a task online, like everyone else, and is unable to access basic features of the product:
Why is this product so inaccessible? Or why are they not focusing on accessibility? Do they not...care?
And this is not just for disabled users who are unable to use a product because of barriers to a11y. This also applies to all users who might have a preference to use a product a particular way -- a heavy preference to keyboard only use (me), trying to watch a video without captions in a public/loud area for example. It is frustrating to constantly work around inefficiencies and a11y gaps in the product because the product is not accessible enough. From the user's perspective, the product is not usable for them and they are frustrated and want an answer or at least some recognition that their voices are being heard and steps are being taken to address them.
At some point, after years of banging one's head against the same a11y barriers, sometimes, the question becomes -- 'Do they not care about us?' and I have to say, it is a valid question. If time and again, opinions voiced by disabled users have not been taken into account, users begin to wonder if they are being heard at all.
I have taken on almost all of these roles in my career -- engineer, accessibility analyst, tester, user and at different points in my life, I have experienced different emotions expressed in this post. I believe the essence of a good experience for anyone (a developer, a manager, a user) is one that generates positive emotions:
As a coder, I am happy if I understand why I am fixing these bugs, how to fix them and the impact they make and if I feel appreciated for the effort I put in (by my manager, by the people who use the product)
As an analyst/accessibility-lead, I am happy if my product is accessible and users, irrespective of abilities, are satisfied and can efficiently use the product
As a manager in charge of a product, I am happy to see it release on time given the time and resources I have allocated (or that I am allowed to allocate) to the project and users report a positive experience from using the product.
As an end-user, I am happy if I can use the product...well.
Now, if only we can all figure out a way to be happy together :-)
To draw an analogy from our very own WCAG 2.0: 4.1.2:
An accessible user interface component is about an appropriate name/role/value, I would add, and an accessible user experience is about people/roles/emotions.
Note: The opinions expressed in this post are mine and not that of my employer(s).
