Tag: accessibility

Categories
Accessibility Technology

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.”

CURRENT PROBLEMS

  • 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

RESISTANCE TO CHANGE

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

FINDING CHAMPIONS

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
ESTABLISHING THE SYSTEMS TO GET YOU THERE
  • 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
TACKLING TECHNICAL CHALLENGES
  • Evaluation tools (Deque Worldspace, SSB BartAMP, IBM Rational Checker, WAVE).  The reports these tools are kind of like a report card.
TACKLING CULTURAL CHALLENGES
  • 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)
ADDRESSING FINANCIAL CHALLENGES (directly from slide)
  • 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
ESTABLISHING THE SYSTEMS TO GET YOU THERE (continued)
  • 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
LEGISLATION, POLICY AND BEST PRACTICES
  • 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.
MEASURING SUCCESS
  • 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)

 

Categories
Accessibility Technology

WCAG Guidelines – What about the Users?

PRESENTERS

  • Birkir R. Gunnarsson, Blindrafelagid; The Icelandic Organization of the visually impaired @birkir_gun
  • Hinni Hreinsson, The Stockholm Low Vision Center @hm_hreinsson

BIOVI (Blindrafelagid, Icelandic organization of the visually impaired), similar to NFB in the US (details directly from slide)

  • Fights for independent and responsible living conditions for visually impaired people
  • Fights for their secured equal rights and opportunities to respnosible, active and recognized participation in all sectors of our community
  • Part of a public medical service of Stockholm County; 80 staff in 5 teams
  • Birkir does audits and makes development recommendations
  • Hinni trains users on AT
  • Discussions between Birkir and Hinni revealed that their best practices recommendations did not always make it to AT trainers and end users

WHY THIS PROJECT?

  • Delivering web content requires 4 players
  • Accessible web site
  • Browsers that render content and build DOM
  • (missed a bunch of items from this slide, sorry!)

To summarize (Paul’s description, so it’s probably butchered):  this is an outreach effort to get the word out about the roles of headings, landmarks, navigation hotkeys, etc.  Wanted to create a survey to help develop a vendor neutral guide to help explain how you can use a screen reader to effectively read web pages.  This would benefit users at various stages of screen reader competence.

WebAIM SCREEN READER SURVEY

  • 1,700 SR users
  • 2/3 of SR users consider themselves advanced Internet users, only 2% consider themselves beginners
  • Users keep their SR up to date
  • (missed details on this slide as well…will try to post link to WebAIM survey results)
  • UPDATE:  http://webaim.org/projects/screenreadersurvey4/

SR USAGE AND TRAINING

  • Many users run multiple screen readers
  • Most have one up-to-date enough to read landmarks
  • 20% received formal training
  • Close to 80% use their SR web page summary feature

FAMILIARITY WITH LANDMARKS, HEADINGS AND TABLE NAVIGATION

  • 60% are familiar with headings and use them for page navigation
  • 60% use navigation hotkeys to browse tables on web sites

NOTABLE RESULTS

  • Most users learn how to browse on their own, with little formalized training
  • Much of user base still relies on TAB and ARROW keys to navigate a web page.
  • Users also use the page description element of screen readers

SUGGESTED IMPROVEMENTS

  • Web developers:  use markup clearly and efficiently
  • W3C standards:  consider a set of more clear specified landmarks
  • SR Vendors:  include landmarks in web page summary features
  • AT instructors:  can we reach out to more users?
  • Make sure AT instructors teach effective browsing techniques

Create educational web resource that would be a simple online user manual on how to effectively navigate web pages.  This would include relevant navigation hotkeys for all screen readers.  Will be written first in English, then translated to Swedish and Icelandic.  Information would be updated as needed.  Possibly have WCAG certification or an associated accessibility statement that links to this resource.

Results will be released at an EASI webinar on May 2nd, at 2pm EST (US Eastern Standard Time).  Sign up at http://easi.cs

Categories
Accessibility Technology

Creating an Accessibility Community

PRESENTERS

  • Jennison Asuncion @Jennison
  • Bob Bosken @bbosken
  • John Croston @jfc3
  • Char James-Tanny @CharJTF
  • Kathy Wahlbin @wahlbin

CHAR:  talked a bit about the Boston Accessibility Group.  Creating a community is a lot of voluntary work, so balance and “me time” is important.  Need a team to help out with normal day-to-day operations like updating web site, ordering pizzas, getting guest speakers, etc.

KATHY:  having consistency in when and where meetings occur is important to developing a routine that member / volunteers can get into.  We do monthly meetings on a day that varies, with time constant from 6:30 pm to 8:00 pm.  Restaurants tend to be pretty hard, because they’re often very NOISY.  Microsoft “Nerd Center” offers free space, it’s centrally located and next to metro stop and other public transportation.  Our topics tend to vary; ask the group for topics and bring in speakers.  Provide hand-on sessions for key topics such as mobile.

Advertising is important!  Some of the things we’ve done:  Meetup, Nerd Center, Social Media, LinkedIn, collaboration with other groups, and referrals.

JENNISON:  power of meetup are keywords (usability, mobile web, etc) are powerful way to generate interest.

BOB:  we started a Meetup group in February, leveraged an existing network of his and his wife’s (an employee of Nationwide Insurance) in Ohio.  “Any warm body I can get in the room” is a goal.  Used EventBrite to send out notifications.  FB and Twitter generally didn’t generate a lot of local interest; it does lend legitimacy to the event though because it gives people a place to go.  Never underestimate the power of food and refreshments.  Everyone is welcome and has something of value to share…giving a platform to people to share ideas and talk about what they’re doing is a great thing.  We were able to do this on a two-week notice, but providing at least a month is much better to ensure attendance.

JENNISON:  We do this in Toronto area.  We use Twitter and encourage everyone to USE DEM HASHTAGS!  (in particular #a11y).  Hashtags often represent communities, so we’ll use hashtags like #webdevelopment, #webdesign, and so on.  This often results in people accidentally stumbling onto your group…this is a good thing.  LinkedIn is synonymous with “your professional presence online.”  LinkedIn groups provide a good way to have longer focused discussions.  We alternate locations each month, one at a design firm, the other is a networking event held in a restaurant.  We have over 200 members, many of whom are students in CS and usability majors.

Build community where you are.  Be visible in as much as the “mainstream stuff” as you can.

I’m involved in the WAI engage group, which is trying to get design / development community engaged with the WAI.

There’s a danger in using social media:  these people tend to be advanced users and geeks.  Don’t forget the other means of communications: list serves, forums and discussion groups, face-to-face meetings, etc.  We need to go to where the high-tech and mainstream communities live; cross-promote wherever possible.  DON’T SCARE OFF PEOPLE WHO WANT TO GET INVOLVED BY BEING OVERLY CRITICAL.

JOHN:  attends WordPress meetups.  Asks people who attend his meetups “what other groups are you involved with?”  He talked briefly about a group he’s been involved with called “DC Night Owls.”  He often provides practical advice about how to do things like make a web form accessible.  Jennison gave a talk at one about how he buys tickets on AirCanada; once had folks give demos of JAWS and Dragon (in the same room, << gasp >>); how to improve WordPress.

Organize annual events!  Have a team to share the work, have flexible dates until the location is confirmed, work on publicity, have a theme, what structure will the event take (full unconference, partial unconference, no unconference).  JENNISON mentioned that his primary audiences are locals and beginners.

CHAR and KATHY on unconferences:  it’s very important to have specific topics.  This helps generate commitment to attend among your people.  Some mechanisms to generate topics:

  • Create a Wiki
  • Use a poll
  • “Winging it” works sometimes
  • Have a misc theme, just in case your primary topics don’t resonate with some

Sometimes it helps to institute a small charge to ensure attendance, think about dietary considerations, but don’t overdo the food angle (can be over thought).  For food, leverage your team, it’s often the forte of someone already on the team.

 

 

 

Categories
Accessibility Technology

Karl Groves: Choosing An Automated Accessibility Testing Tool

Karl Groves @karlgroves

This is my first time seeing Karl IRL, I’ve followed his posts pretty regularly over the last few years, so I’m excited for this session.  Karl briefly talked about being a Viking and some of that lore was colorful.  Sweet, I’m in 🙂

Also talked about testing tools and asked the audience about the kinds of tools people are using.  Examples:  ACCVerify, Firebug, WAVE toolbar, and so on.

Automated testing has an unbeatable cost per defect cost ratio.  However, it finds things it’s designed to find.  Find things that are machine-testable.  Some of the earlier 1st gen toolss:  LIFT, Insight, ACCVerify, Bobby, etc.  These were often desktop software and typically searched strings.  Karl lost a job with the GAWDS due to a 1st generation tool that rejected his site because of an automated tool’s report.  Blech!

2nd gen tools have a lot of differences.  They’re almost universally web-based because they’re easier to deal with, and more importantly, eliminate the problem of a lack of collaboration engendered by 1st gen tools.  They’re also more efficient at managing testing criteria, thresholds and standards.  They do have weaknesses though.  They can’t test every single thing, you’ll never get full coverage (in fact, only as much as 17% at best!), and some WCAG success criteria cannot be tested AT ALL.  That’s where manual testing (human review) comes in.  Also, you’re never quite sure what they’re actually testing:  the DOM or the string.  Accessibility APIs work with the browser and assistive technology.  If you’re not testing the DOM, you’re not testing the user experience.

QUOTABLE QUOTE:  “Your HTML is a polite request to the browser”

Primary Criteria for selection

  1. Is the tool user friendly?
  2. Quality & reliability of results (does it generate a lot of false positives?)
  3. Does it test the DOM?
  4. Is it web based?
  5. Integration (these tools are generally separate systems)
  6. Does it spider?  (this is useful for sites that constantly add tons of new content)
  7. Does it test uploaded / submitted source? (gets developers to test code while they’re working)
  8. Monitoring and Retesting (keep an eye on things)
  9. Manual Test Guidance (does it give us info on how to test suspicious stuff?)
  10. Standards and test management (can we make the tool work for us?)

MAKING YOUR CHOICE

  • Take your time
  • Take a test drive (ask for full working license for 30 days…don’t just sit through a 1 hour canned review)
  • Demand satisfaction

QUESTIONS

  • What about users with different / older versions or client settings?  At some level, the organization has to draw a line in the sand about what they support.
  • There’s a W3C effort to crowdsource testing tools, criteria and thresholds
  • Can you talk about the tools you currently use and have used?  Each has their benefits and drawbacks.  Like FireEyes, Favelets.
  • Given resources, how do you weigh buy versus build?  Tool needs to work the way I need it to work.  Is there open source stuff available?  Peter:  might be one in Greece, Open Ajax tool and open rulesets.  U of Washington “before and after” examples.
  • Another criteria:  does tool upload test data to a remote server?  This could be a problem for some.
  • Karl has a whitepaper available:  to get it, e-mail him at karl@simplyaccessible.com

 

 

 

 

Categories
Accessibility Technology

Google Accessibility – Partially Digested Observations

Holy moly, that was an information-packed session today!  And, what a difference from last time I saw Google at #CSUN.

I saw Google’s presentation on accessibility when I attended the #CSUN conference (I believe) four years ago.  At that time, I got the impression that Google was “phoning it in.”  The reps they sent at that time were clearly lower-level, more tech-oriented staff and didn’t present their story to the #CSUN audience in a compelling or memorable way.  If I were cynical, I’d say their approach at that time smacked a bit of technical smugness.

Fast forward four years…

Today, there were no fewer than 15 people from Google, including product managers from their core applications, internal accessibility evangelists, and development staff.  They’re not messing around now.  Here are some of the standout items, from my perspective:

  1. Google’s development team is working hard to standardize keyboard navigation across their core applications.  This is huge, and will pay big dividends for all users in the very near future.
  2. For obvious reasons, Calendar was not mentioned much.  To Google’s credit, they did not evade critical questions.  Calendaring is freakin’ hard – my team made a public web calendar for the CSUN campus a few years back, and I can assure you that that effort was no joyride:  www.csun.edu/calendar
  3. Google acknowledges the problem of keyboard shortcut collisions.  Sorry folks, there are no “standard” keyboard shortcuts but the ones that have come about due to historical cruft of the software industry.  People using niche apps will unfortunately be caught in the lurch.  This isn’t all bad though, because…
  4. …Google’s larger plan is to have their entire ecosystem in the cloud.  Like it or not, this is the future of computing.  This hearkens back to a conversation I had with my Computer Science colleagues regarding “the cloud” about five years ago.  My question back then was “what happens when everything is available in the cloud?”  Answer:  “we pick and choose those services that we need and trust.”  Google is building those services today, and from what I can see, I trust that they’re working on it.  BUT…we have to continue to push for more accessibility.  If we don’t evangelize and make it a priority, it just won’t happen.
  5. Speaking of evangelism, I get the distinct sense that the push for accessibility within Google is an uphill battle at times, but the organization is really starting to “get it.”  Working as a director of a web development team in the CSU with responsibilities around ensuring accessibility on my campus, I can relate.
  6. The advances in accessibility built into the Android OS (Accessibility Service Framework and APIs) are downright impressive.  The work around creating an intuitive “navigation language” alone merits a gold star in my opinion.
  7. Google’s position of supporting current browser version “minus two” is a goddamn blessing and should be shouted from the mountain tops.  I feel very strongly about this, and have written a browser support statement to clarify why I take a similar position with my team’s work:  http://www.csun.edu/sait/web/browsers.htm

Maybe it’s just me being cynical again, but I could kind of sense a faint hint of technical smugness today.  Its character was different though, and I think that comes from the audacious scope of what Google is trying to do as a company.  When you throw around statements like “the web is our platform,” I guess it’s hard to be humble.