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:
- Adobe flex client
- HTML-desktop site
- HTML (the accessible one?)
- Mobile (iOS, Android, mobile web)
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.
Alastair, “safe harbor” is the notion of a condition you can reach, or that they can define clearly for you, that means you’ve done everything you need to do and, because you have, everything will work.
More likely, they were warning folks of “no safe harbor”—in other words, that just because you do everything they say, there’s no guarantee that it will produce the result you need.
The term is used a lot with respect to regulations. For example, the US Communications and Video Accessibility Act (CVAA) prohibits the regulatory agency that enforces it from defining a “safe harbor” of compliance.
In other words, content covered by those rules must be accessible to and usable by people with disabilities, period—even if that requires measures that didn’t exist when the law was written.
Under “User Stories,” Jacob came from A Web for Everyone, by Whitney Quesenbery and Sarah Horton.
And I agree with you that the personas used for accessibility should not be separate from the others. The short answer I have for Agile teams is that the best way to consider accessibility is to add this statement to the end of every one of their user stories: “even if I cannot see, hear, manipulate objects with fine motor control….” In other words, consider all disabilities that might impede successful accomplishment of the task entailed in that user story.
But, as you note, you don’t need new user stories. You just need to be sure that the user stories you do have actually do work for everyone.