WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessibility for Project Managers - your thoughts?

for

From: Will Anderson
Date: Sep 21, 2013 12:12PM

Hi everyone,
Based on my experiences in the past year introducing accessibility to a
large legacy project, I was thinking about writing something I've
tentatively titled

"A practical guide to introducing accessibility to legacy projects"

Here's the rough outline I've got so far:

1. Introduction to the guide and links to everything it's not
1. *It is* meant to give practical advice for renovating existing
applications and incorporating accessibility thinking into your
process in
a prioritized step-wise fashion.
2. *It is *based on my experience introducing accessibility into one
project so some lessons may not apply in other contexts.
3. *It is not *an argument for incorporating accessibility into
products
4. *It is not* an argument for what counts as accessible. Each
product needs to determine that for itself when it comes to the details.
2. Background on the project these learnings came from
1. Small-medium sized team (roughly 25 developers, 6-8
product/project managers, 3 qa, 2 help desk, 4 designers)
2. Required to meet 508 standards but want to be accessible to all to
increase usability
3. Agile and test driven development development processes
4. Ruby on Rails and open source friendly
3. Steps
1. Gain executive buy in to begin aligning resources toward building
accessibility and ensure the rest of the team
2. Identify key stakeholders from different business units to be
local champions
3. Identify your application's a11y successes and failures. If you
can't do this, figure out a learning plan so that you can identify the
successes and failures.
4. Prioritize the failures in a way that makes sense for your
application and impact on your users
5. With stakeholders and execs, write a plan to spread knowledge
across all relevant business units
6. Start spreading knowledge
7. Reinforce executive buy-in
8. Prioritize spreading practical knowledge in your development
process. For example, we focused heavily on our developers to prevent
releasing more inacessible implementations and, once good there, went up
the design chain to product managers and design.
9. Create and begin tracking progress toward better accessibility
10. As you gain practical experience, identify tools which help
identifying a11y issues or prevent them from occurring again
1. Example for identifying issues: a11y users testing and
capybara-accessible or other automated testing for really
basic alerts
2. Example for preventing them from occurring again: centralize
design patterns in a live style guide that is continuously human and
machine audited
11. Celebrate major milestones in accessibility
4. Processes/ideas that really worked
5. Processes/ideas that didn't


For each of the above steps, I was thinking about breaking down what you
should expect each role in a team to be doing. Throughout, project/product
managers would be gluing the effort together and pushing it forward while
other roles would drop in and provide different skill sets.

What do folks think - useful? Any topics seem off base or missing from the
outline?

Regards,
Will


On Sat, Sep 21, 2013 at 4:35 AM, Tim Harshbarger <
<EMAIL REMOVED> > wrote:

> I'll be glad to work with others on such a thing, but I will mention that
> I think that one of the problems I find with checklists is that they tend
> only to be useful to people who understand the items on the checklist.
>
>
> For example, people often state that following WCAG 2.0 can still lead to
> an application being inaccessible. I agree with this to some degree, but
> not totally.
>
> I have previously done some work with relationship to usability...and when
> we create style guides, we would often say that one can follow the style
> guide and still end up with an unusable site.
>
> However, whether you are following a style guide or WCAG 2.0, a failure to
> make something either usable or accessible based on those things tends to
> be less an issue of the style guide or standards and more a problem of the
> implementers level of knowledge or skill on the topic.
>
> So, I think it is valuable in any kind of presentation to provide people
> with a take away, one of the drawbacks of a checklists is that you need to
> ensure they walk away with enough knowledge to make proper use of that
> checklist.
>
> Thinking about it, I suppose you share similar thoughts--and perhaps I'm
> overly sensitive to the issue because I've dealt with some people who
> either think checklists are evil or people who really want a checklist to
> be a cure all--and I expect a checklist isn't really any different than a
> hammer--a great tool when in the hands of a skilled carpenter and a really
> bad idea when placed in the hands of a 2 year old. At least, I've not met
> any toddlers to whom I want to hand a hammer--even if I wanted to use it as
> an illustration for accessibility purposes.
>
> And for those of you who know me..please, if I ever look like I'm going to
> hand a hammer to a 2 year old because I have some crazy idea that it might
> make for a good illustration for a presentation, I beg of you to save me
> from my own creativity. While I have no fear of my own creativity, it is
> probably a good idea if others do.
>
> Thanks,
> Tim
> > > >



--
Mobile: 917-330-9016