Tag Archives: culture shift

The CSUN 2013 Web Track Mega Post

Greetings, fellow web accessibilistas!  (not to be confused with accessiballistas, the little-known and even less-documented accessible siege engine of yore).

As you may have gathered if you followed my live blog posts a couple weeks ago, my interest in attending the CSUN 2013 conference was almost exclusively web-related.  Now that it’s been a couple weeks and I’ve had some time to reflect, I figured it would be a good idea if I consolidated everything into one mega-list.  This year, there were several times when I wish I could have been in two places at once.  Hopefully this gives you a pretty representative sampling of what was on offer web-wise this year.  Follow me @paulschantz for more web-related topics, including accessibility, project management, web development and design philosophy, thoughts on working in higher education, bad clients, off-color humor, and other ephemera.  Enough self-promotion…on with the list!

Pre-Conference Seminar:  Google Accessibility

Day One:  February 27, 2013

Day Two:  February 28, 2013

Day Three:  March 1, 2013

Be the Fireman, Not the Cop

John Foliot @johnfoliot / http://john.foliot.ca

Laying the groundwork for online accessibility success in a large environment.  Boy, this is something I can relate to 🙂

QUOTABLE QUOTE:  “Close only counts with horseshoes and hand grenades.  Perhaps web accessibility compliance should be added to that old saw.”


  • Lack of accessibility planning / pre-planning
  • Stakeholders already on the defensive
  • Tight deadlines
  • How much does it cost?  No budget allotted
  • Content being developed for the web was never designed with web accessibility in mind
  • Sum Total = Resistance


How does it manifest?  Confrontation, rejection (doesn’t apply to my content), avoidance, insincerity.


Takes a cultural shift, and requires good communication and communicators.  He read Malcolm Gladwell’s The Tipping Point.  From this, he realized that you need to find the “Connectors.”  They know everyone, have done everything, and have the institutional knowledge.  Also need to identify the “Mavens,” who in our case are the hard-core geeks who do the implementation; they’re the early adopters.  Also need “Salesmen” as well, provide boosters, promoters, persuader, helper (enthusiasm).

COMMUNICATION SKILLS (directly from slide)

  • Be likable, and stay positive
  • Connect – find mutual points of interest (be sincere)
  • Solve problems and build trust.  Teamwork starts with you.
  • Create positive experiences and make learning fun! (i.e. – things are challenges, not problems)
  • ID and work with the Connectors, Mavens, and Salesmen
  • Tackling technical challenges, such as using a publishing and tracking system like Drupal, CQ5, etc.
  • Select a tool to track bugs like Bugzilla, Mantis, Trak
  • Use frameworks like jQuery and Dojo
  • Consider custom tools (when necessary).  Example given was Stanford’s caption tool.
  • Look for ways to automate processes to make user’s lives easier
  • Evaluation tools (Deque Worldspace, SSB BartAMP, IBM Rational Checker, WAVE).  The reports these tools are kind of like a report card.
  • Provide detailed expectations of outcomes, not process (don’t tell them HOW it’s going to be done).
  • Set realistic goals
  • Encourage creativity (your users will have some great ideas)
  • Lay out the efforts as challenges, not consequences (tell an engineer you can’t figure out a problem and then walk away)
  • Pursuit of quality:  don’t let perfect be the enemy of good
  • Set timelines and milestones
  • Celebrate successes!
  • Foster empathy and understanding (brown bag events – invite actual users with disabilities)
  • It will cost money (you can pay me now, or you can pay me later.  Eventually, you have to pay me)
  • Be honest about what it’ll take
  • Scaled question – the longer you delay, the more it costs
  • Transition towards a team based approach (PM, tech team, Design and UX, Marketing / Content Department
  • Identify bottlenecks for each group independently
  • www.w3.org/community/wai-engage/wiki/Accessibiilty_Responsibility_Breakdown
  • Establish training and internal resources
  • Motivation (internal awards, recognition, etc.
  • Document knowledge internally with a wiki or Knowledge Base
  • Be consistent in your implementation
  • Accessibility is a governance issue and a shared responsibility
  • Appeal to pride versus fear (your efforts matter and reflect well on the institution, we’re the best, that sort of thing).  Audience members commented on tying accessibility to something that matters to the organization.  An example of this might be brand.
  • Get some policies in place:  work with existing standards; avoid re-inventing the wheel.  Again, there is no such thing as perfect.
  • Legal threat is heavy-handed and should only be used as a last resort
  • There was some discussion regarding the involvement of lawyers.  My own commentary (not voiced) is that people only hate the lawyers because they make the rules and know ’em well.
  • Avoid the checklist mentality
  • Avoid appearances of concessions and sacrifices
  • Avoid the brick!  (Giant report)
  • More than just a QA process, multiple rounds of accessibility testing
  • Work with milestones, test early, test often
  • Be specific in what you ask for, generous in what you accept
  • Celebrate successes and recognize efforts great and small (this does matter)