CSUN16 Survey on Web Access and Assistive Technology

Summary

From the end user's perspective, accessibility is simple. Either it works as they expect, or it does not. When it doesn't, it gets bounced back to the web developers, and officially becomes their problem. But is that really fair?

While it is true that developers are in a key position to "fix" the immediate problem, it is not always the right thing to do, and can actually be harmful to the evolution of accessibility.

It Takes a Village to Raise an Accessible Website

There are many different players involved in the process of getting information from the webpage code to the end user:

The web developer (here the term includes the content creator and designer) is responsible for making sure that the webpage is coded according to accessibility standards.
The browser parses the webpage content and maps it to the operating system's accessibility API. Thus the accessibility tree is born (or grown).
The Assistive Technology application plucks the fruits of information from the accessibility tree and makes it available to the end users.
The end users interact with the webpage content as presented by their assistive technology application.

Notice how accessible content is a lot like fruit salad?

To put this in terms of responsibilities:

The webpage content developers, designers and creators are responsible for creating accessible and standards-compliant webpage content.
The browser is responsible for correctly mapping the web content to the accessibility API in the operating system.
The operating system is responsible for making sure its accessibility API can accommodate all types of webpage content and controls.
The assistive technology application is responsible for parsing the accessibility tree, processing its contents, and communicating the information to the end users in a manner they are most comfortable with.
The end users have to understand how their assistive technology application works and be able to take advantage of accessible content.
The PM and procurement managers have purchased an authoring tool (Word processor, spreadsheet tool, WYSIWYG web dev tool, CMS, eLearning system) that does not allow for the publishing of accessible content.
The authoring tool users who may be unaware of the settings to generate more accessible content if those features are hidden in the tool.

This list does not represent the complete picture. The web development team consists of designers, developers and content creators who work together to create websites, sometimes using third party solutions such as content management systems and code libraries. The accessibility and web development standards lay down the rules for web content and are responsible for allowing progress while ensuring a better user experience for everybody.

But we felt, in the interest of getting answers, that this slightly simplified picture of accessibility would be sufficient to highlight the problems and gather valuable opinions from the community.

And let us not forget the role of the accessibility subject matter expert.

The SME's job is to locate the accessibility issues and find out what caused them. In the vast majority of cases repairs can be made in the webpage code. But when the problem is caused by standards, browsers, accessibility APIs in the operating systems, or Assistive technology applications, it is the job of the SME to make sure that information gets shared and that hardware and software bugs can be addressed to ensure better accessibility tomorrow.

Short-term Repairs Vs. Long-Term Improvements.

The web developer is the (wo)man on the spot. They have to navigate the complex world of coding and standards to make sure their web content is accessible. This involves coding to standards, using native markup when possible and providing all the necessary roles, states and behaviors in an accessible way when they choose to create custom elements. In the ideal world of tomorrow, the web developers should only have to worry about valid code, the rest will take care of itself.

But sometimes we are faced with problems where a webpage is coded correctly, but deficiencies in the other parts of the accessibility chain prevent the content or functionality from being communicated to the end users.

The developer can usually find a way to correct or hide the problem with additional coding. But if the problem is caused by defects elsewhere in the accessibility chain, hiding the problems today may actually prevent them from being fixed so the developer does not have to encounter the same problem tomorrow, or in a month. And when different developers apply different fixes to the same problem, the users will never have a consistent and predictable experience.

At the same time filing an issue in somebody else's issue tracker takes time and effort, and will not solve the problem for the end user who needs access to your website today.

This is the core of the dilemma that we as accessibility subject matter experts face every day. We need to know when to recommend that developers apply fixes, when to file bugs with the relevant technology vendors, when we see the need to improve existing standards, or recognize that the problem is not technical but lies with the end users' lack of training or information about their assistive technology application.

As accessibility experts we need opinions and ideas from developers, technology vendors and end users alike to help us prioritize common issues, get the information to the people who can fix the problem and tell developers to what extent they should go ahead and apply patches today while the underlying technology is being fixed.

The point here is we need to determine the root cause of what is making content in-accessible.

That is the purpose of the survey we have created.

The Survey

In this survey we want to ask you, - the readers - with your varied backgrounds and perspectives, how we can make the process of making web content accessible more transparent, and how to balance implementing workarounds for today's problems while helping to ensure the same problems will be gone tomorrow.

We do this by presenting you with 10 scenarios where there is an accessibility problem that can be caused by one or more players in the accessibility chain. We ask you to offer up your insights and opinions as to how a theoretical developer should act to balance the accessibility of fixing the content today with moving accessibility forward. Most of the scenarios presented reflect real problems we have dealt with personally or professionally, and none of them have a clear and present solution.

Each survey question consists of a coded example of a problematic situation (one that you can reproduce with the assistive technologies specified), along with an explanation and an imaginary scenario. For each scenario you have the question "whose line it is anyway", which essentially means, who is responsible for this problem and should the developer try to fix it.

We readily admit that our own survey suffers from one of the core problems that web developers deal with on a daily basis, we could not find an embedded survey solution that satisfies WCAG 2.0 AA accessibility requirements. We were faced with the poor man's choice of using an inferior solution or not conducting the survey at all. After testing a number of imperfect survey tools, we settled on using Survey Monkey. The problem with the Survey Monkey embedded solution is that the question is not marked up as a common label for the answers. We wanted to fix this problem using JavaScript, but that cannot be done with the embedded survey content. Since all the questions, except the first, are identical, they simply say "whose line is it anyway", we felt this was a sufficiently accessible solution. Rest assured that we informed the Survey Monkeys, and we hope this will encourage them to fix the problem.

What's in it for me? Will I hear anything back about the survey results?

Certainly! We are going to share the survey findings at a CSUN 2016 presentation predictably titled "Whose line is it anyway?". For those who cannot make it to sunny California we will publish one or more blogs about the survey results and our commentary through the Accessibility Matters blog in the spring. If we learn something from this experiment, we'll do "our durn best" to make sure you will learn it too!