WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: A11Y and Agile Methodology

for

From: Karl Brown
Date: Dec 22, 2016 7:58AM

I've found great success on the current agile project by making myself
available for questions, discussions, documentation and demonstrations.

I'm a content writer at my main employer (where this project is), but
answer a lot of questions about accessibility because I'm approachable and
easy-to-find. I've provided training to the other content team members, am
supporting and training the UX and UI designers, and test completed pages
from the front end developers. If the developer has a question during
development I'll sit with them and guide them as well.

It's not been part of a formal process, which is why it's worked well on an
agile project. Despite having access to accessibility companies (3rd
party), because they have someone who understands a11y on site, I'm the one
who gets asked more often than not.

In terms of implementing it into an agile approach:
1) Have accessibility professionals on site. If they can be multi-skilled
(e.g., can write content, design, do code, etc.) the company will benefit
from a multi-skilled employee
2) Have the accessibility professionals available as part of a "shared
service" between teams and projects
3) Allow the natural relationships between the accessibility professionals
and the teams to build
4) Make sure every aspect of the project has some training, with refreshers
available for people who need it
5) Never release anything that's not been through accessibility testing
5a) Try to do testing every feature, or every sprint if the developed code
warrants it
6) Make sure people know they can always go to someone with questions

Point 6 has been a big piece of feedback I've gotten - people respond
positively to the fact I reply quickly to emails or stop what I'm doing to
answer their question if they turn up at my desk. I also don't say "Do
this" without walking them through the reasons as well, making sure they
understand it. I see my accessibility role as a teacher more than anything,
which has worked well in agile.


On Thu, Dec 22, 2016 at 1:55 PM, Tim Harshbarger <
<EMAIL REMOVED> > wrote:

> I do not have any resources, but I have some experience with this issue.
>
> When I think about the advice I would offer to others, I think the advice
> on integrating accessibility for both waterfall and agile methodologies
> would be the same. Optimally, everyone on the project team should have
> some level of accessibility knowledge appropriate to their role. If that is
> not possible, there should be at least one person integrated into the team
> that has a level of accessibility knowledge. Use automated accessibility
> testing tools as part of the build process. They can't check everything,
> but they can check at least some things which reduces the number of things
> that you might want to check manually.
>
> I think the big difference between waterfall and agile is the timing of
> the feedback loops. In agile methodologies, you can have a build of the
> application daily or even more frequently and an implementation every 2 to
> 4 weeks--depending on your agile methodology. So, having that level of
> accessibility knowledge integrated into the team and using testing tools in
> your build process becomes even more essential to success.
>
> Probably most of us are familiar with the traditional model of
> accessibility that frequently involves a project team throwing a UI or
> design specs over the wall to an accessibility expert. The expert reviews
> the UI or specs and tosses feedback to the team. The team then integrates
> the feedback into the application--hopefully. That traditional model does
> have the advantage that you apply the maximum level of knowledge to each UI
> and the expert can work on multiple UIs. But it has the problem of time
> because the feedback loop takes more time. It also means that you can't
> take maximum benefits of opportunities for accessibility because the
> accessibility expert typically sees things after they are completed--when
> the team is done making changes. You end up having to patch bad UI's with
> sub-optimal accessibility fixes rather than employ the optimal
> accessibility solution for the situation.
>
> In waterfall, you can get away with using that traditional model or some
> part of it. I don't think it is really possible to use that model
> effectively in agile.
>
> In agile (even more so than waterfall,) probably the best role for an
> accessibility expert to play is to provide resources like documentation and
> education on manual testing processes and other things, ensuring the
> frameworks and other technologies used by the project teams are as
> accessible as possible, and helping out with more complex accessibility
> issues that project team members don't have the level of accessibility
> knowledge to handle.
>
> Thanks for asking such an interesting question.
>
> Tim
>
>
>