CSUN: Accessibility in an Agile World

Amy Chen, Olga Sokolova and Beth Bemis talk about how they incorporate accessibility into the agile process at Workday. They are a cloud HR software company.

They start off with a 'safe harbour statement', some kind of caveat I didn't understand, probably because I'm not from the US?!

What is agile development?

See the wikipedia page or agile manifesto, but incremental change is a key factor.

They did a couple of polls, it seems most people use Scrum as the main agile methodology, and there are a variety of people's roles.

At Workday

At Workday they have a central Accessibility subject matter expert (ASME). The ASME is the contact-point for all product teams. The also have meetings with representatives from product management.

And, they have an accessibility scrum team. An independent team that supports the dev on the accessibility functionality. The accessibility product owner writes stories for the accessibility functionality and prioritises them. They interact with customers and internal stakeholders.

Typically they have 4 week sprints, month long, and their coding in XSLT / Javascript rendered to HTML.

They have a multi-client architecture, a UI server producing different interfaces for:

The example of "desktop site" and "HTML" shows a nice looking screen with icons + text, and an old-style text HTML page of just text. (AC: Starting to loose the audience at this stage. It isn't really talking about agile process, it's more about the technical architecture.)

Question from the audience: Do you see any issue with the separate experience? Yes, it's not ideal, but it's what we have now.

QA for accessibility

At workday they do a weekly "smoke test", they manually login with different roles, keyboard only. Also have automated tests built in Selenium.

This seems to rest with the accessibility scrum team, rather than the product teams, which is different from the themes I heard from Facebook and BBC.

They also do usability testing for accessibility, primarily with Jaws. E.g. log your time off, procurement, manager approvals, expense reports. There was a brief interlude while a gentleman from Webaim went through the screen reader survey results.

NB: Some companies don't let the teams gather information about how many screen reader users there are.

User stories

After showing a typical user-story template, for accessibility we can write user stories form the role of a persona, end-user with disability.

Taking an example from "the web for everyone", Jacob is one of their personas.

A user story was: As a screen reader user of the Workday accessibility functionality, I want to use heading navigation functionality to jump to various places on the page.

(AC: This seem fundamentally flawed to me, the range of people who have any particular disability or technology need is as wide as the general population. It is orthogonal to personas, it can only marginalise accessibility.)

Someone from the audience suggested sneaking them into the base personas, rather than having separate ones.

The example of confirmation of the story (not having layout tables read-out) is reasonable, e.g. role=presentation should be used on certain tables, except those that are needed.

However, it is really just dressing up feature development, this type of thing should be part of the development practice, not a separate feature.