Presenter: Denis Boudreau
This was my fourth presentation at the CSUN conference on Thursday, March 5. I’ve known Denis via some conference calls with W3C, and of course I’ve seen him a few times at the CSUN conference. I’m looking forward to this presentation, but the headache I woke up with this morning is getting worse. I will try my best to capture this one.
Denis talked a little bit about a project he worked on years ago where there were issues with color contrast in a company rebrand (yellow and light blue on a white background – yech!). Question the project manager posed to the designer was WHY DIDN’T YOU KNOW THIS? This story highlights the gaps and communication breakdowns that can occur, even when an organization has committed to accessibility.
Lessons Learned “The Hard Way”
User stories to reflect common issues:
- “Amy” web accessibility specialist, tasked with assessing redesign against WCAG AA. Discovers no prior testing has been conducted. Site launches in two weeks. LESSON: dealing with web accessibility at the end of the project lifecycle leads to costly retrofit that could’ve been avoided.
- “Roy” accessibility coordinator, leads the accessibility task force in his Fortune 100. Role is making sure they never get sued. Leadership has not provided clear top-level support. LESSON: without clear top-level support from leadership, web acc champions are ultimately bound to be ignored by their peers.
- “Elena” QA lead, org is under litigation because their web site was inaccessible to people who are blind. She built an accessibility checklist. LESSON: centralized testing teams who fail to include end users testing in their process are likely to miss significant issues when assessing content.
- “Chris” business analyst tasked with selecting the next platform for next redesign, has 3 products with VPATs that claim 508 compliance. Redesign will be done by an offshore development team. LESSON: never underestimate the impact of external factors – for they can make or break all efforts towards web accessibility.
- “Mike” front-end dev, gifted web dev who realized long ago that accessibility was mostly about testing with your keyboard and using native semantic HTML. Introduced his team to various browser toolbars and everyone now feels confident they have accessibility covered. LESSON: developer toolbars, semantic markup and automated testing tools can only get you about 30% of the way towards web accessibility goals.
- “Julie” Accessibility champion in an organization working toward digital inclusion. With so much work to do, and so many people asking for help, and so little time to get it all done, she often becomes a bottleneck. LESSON: access resources who allow themselves to become bottlenecks give everyone else an excuse to overlook web accessibility.
What do these people have in common
- They believe they’re doing the right thing
- pretty much left on their own
- ultimately bound to fail
Compliance is Overrated
- No organization has ever been sued over a failed success criterion.
- What orgs are sued over are the results of poor user experiences.
- You need to test with real users
Why is Accessibility So Hard?
- http://webaim.org/projects/practitionersurvey
- Lack of skills and knowledge
- Lack of awareness
- Lack of budget, resources
- Hinder look, feel, or functionality
I did my own survey…
- …and asked 100 people what they thought
- WCAG is NOT a reqs document
- Excuses: time, money resources
- too much documentation, no real-world examples
- Ruins my creative fun
- Never seen AT in use (unknown is hard)
- Don’t know, don’t care
- Can’t be bothered
- In the end: accessibility is not a project with start and end dates, it’s a program. A lifelong, ongoing program.
Integration in the Lifecycle is Only One Part of the Solution
- Take ownership
- Awareness: training & learning, building the business case, sharing the message, etc.
- Alignment: Internal and External policies, accessibility support groups, standards and guidelines, etc.
- Realization: Best practices, design patterns, style guides, tools, testing methodologies, etc.
Whose Job is It, Anyway?
- Everyone, BUT…each individual has a set of responsibilities that’s a part of the ecosystem.
- If people say accessibility is not their job, just ask: “Is quality a part of your job?” The answer is yes, of course.
- Every stakeholder involved needs to stay alert and pay attention to accessibility at their level in the ecosystem
- Everyone needs to be accountable. Share responsibilities.
- Make subject matter experts in your lifecycle accountable, so the right questions are asked at the right time by the right people.
- W3C WAI-Engage Wiki: Distributed Responsibilities Model
- Successfully planning the right intervention at the right time by the right people will prevent costly errors & oversights
- Uneducated decisions will yield significant consequences for accessibility later in the project.
Quality is Everyone’s Responsibility
- Prevent instead of treat
- Share responsibilities across disciplines
- Sense of collective ownership
- Prevent errors & oversights
- Exceed compliance goals
- Meet end user’s needs
- Above all else, accessibility is about building a better quality product
Failing to Plan is Planning to Fail! Web Accessibility is both the journey and the destination.
