Category: Technology

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

The Open Web Platform: Mobile Accessible HTML5

PRESENTERS

  • Judy Brewer, Director of Web Accessibility Initiative, W3C
  • Jeanne Spellman, Web Accessibility Engineer, W3C/ WAI

Judy is covering what WAI is up to right now, went through slides that provided a fairly ridiculous amount of background information about W3C, HTML5 capabilities.  Basically, this is a list of stuff that she covered.  To learn more, see links in the text below.

Elements of the Open Web Platform (OWP)

  • HTML5
  • CSS
  • SVG
  • TTML/WebVTT
  • MathML
  • WAIT-ARIA
  • IndieUI
  • more…
  • New accessibility approach, better progress
  • Waht to use, what to watch

Where to learn more

 

HTML5

  • A full programming environment for cross-platform apps with access to device capabilities
  • Integrated video, animations, graphics
  • Style, typography
  • Plug-in free rich media games

Accessibility Concerns with HTML5

  • Broader range of functionality to support
  • Has to do this within a high performance, small footprint

 

HOW CAN WE MAKE THIS ALL ACCESSIBLE?

One key aspect of W3C is Web for ALL

WAI

  1. Accessibility support in technologies
  2. guidelines, standards
  3. evaluation resources
  4. education, outreach
  5. coordination with research
  6. standards harmonization

 

WAI APPROACH

Multi-stakeholder, consensus-driven, open and transparent processes.  We do a lot with lists and drafts.  Guidelines approach is stable that allows for adaptations.  Authoring tools guidelines, content guidelines, and user agent accessibility guidelines (very relevant for mobile environment).  Web technologies move rapidly, of course…

Core spec is HTML5, but many other specs (CSS, SVG, haptic CSS, etc).  HTML5 is in “Candidate Recommendation.”  Focus is on implementation testing; scheduled to be completed in 2014; already heavily used for mobile.  LOTS of testing is going on right now.  ARIA, Canvas, Text tracks, Native (markup that’s helpful for navigation), improved error reporting in forms completion.

Imperative to complete HTML5 soon, BUT accessibility is also an imperative.  Implementing provisions in “Plan 2014” for smoother / faster progress.  Task force extensions underway or anticipated:  ARIA in HTML, HTML5 Image description (longdesc).  Using the extensions approach to:  directly build what’s needed to support accessibility, decisions get made by people with accessibility expertise, schedule is independent of HTML 5.0 and 5.1, extensions can continue to involve.  Possible problems:  could potentially affect update.  Open Web Platform is a buffet, not a strict set (vendors are picking and choosing anyway).

Task Force is constantly addressing accessibility issues, removing buggy alt guidance, removed meta-generator exemption, still need (for instance) alt text length threshold for figure-captions, need better longer textual description mechanisms for video.

ARIA is a key component of OWP, and is a standalone technical specification.  It is itself a Candidate Recommendation.  There are 2 explanatory documents, using WAI-ARIA in HTML5, ARIA authoring practices.  Steve Faulkner is working on this.

MOBILE AND ACCESSIBILiTY

EXAMPLES OF COVERAGE IN WCAG 2

  • Labels for buttons and control
  • Contrast
  • Captions, transcripts
  • Audio desc
  • Adaptable layout
  • Focus visible

USER AGENT ACCESSIBILITY GUIDELINES

  • 2.0 guidelines are in working draft
  • Accessibility of browsers, media players, mobile devices
  • Extensive user scenarios for mobile accessibility
  • Hoping that calling out needs will nudge OS makers to provide support

INDIE UI

  • An abstraction that interprets events across different device types / layers
  • Maps user input events to intended functions (i.e. scrolling via touch, mouse, keyboard, speech, etc.)
  • Allows web app to get info about user needs and preferences
  • Some security and privacy issues need resolution
  • Some browser manufacturers are at the table on this, but not all of them

MOBILE AND ACCESSIBLE:  EDUCATIONAL

  • Roadmap, updated twice a year
  • WCAG to MWBP (Mobile Web Best Practices)

ADDITIONAL COMPONENTS OF OWP

  • Media and interchange formats (TTML, SMPTE TT, WebVTT)
  • W3C wants to be agnostic with regard to video formats; unable to harmonize onto single format
  • Better support for captioning

MEDIA ACCESSIBILITY USER REQUIREMENTS

  • Alternative Content Technologies
  • System Requirements

MATHML

  • Accessibility support is available
  • APIs are available
  • Browser support is only partially available

USING COMBINATIONS OF OWP ELEMENTS

  • Online learning
  • Games
  • TV on the web

ACCESSIBLE DIGITAL PUBLISHING

  • E-Pub3 (DAISY accessibility reqs, HTML5, MathML, SVG, Canvas, JS interactivity, video)

ECOSYSTEM FOR WEB ACCESSIBILITY

  • Technology foundation (universally designed technologies, interoperable APIs)
  • Motivational context (policies, reqs, business cases)
  • Implementation support (educational resources, training, demos, sample code)
  • Validation and Conformance (validation tools, conformance models, evaluation metrics, heavy testing)

THE WAI WEB SITE: GETTING INVOLVED

  • Getting stared
  • Designing for inclusion
  • Guidelines and Techniques
  • Planning and Implementing
  • Evaluating Accessibility
  • Prestations and Tutorials
  • www.w3.org/WAI/

QUESTIONS

  • There are so many standards we’re chasing right now…when will we be able to “ride the wave?”  Answer (which is also a quotable quote by Tim Berners-Lee):  “It’s like rebuilding all the capabilities of a computer, on the web.”  Some organizations are contributing engineering time to the testing effort.
  • Regarding testing of extensions, do we have a list or schedule of when it will be done?  Answer:  should see a public working draft in the next week or so.  What happens after that, need to see what comments are received.  Much of this will be done via parallel testing of extensions.  We’ll be working to get a done working draft as soon as we can.
  • What’s the one thing we can do to help that would have the greatest impact on mobile work?

 

GET INVOLVED WITH WAI, people!!

 

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