All posts by Paul Schantz

CSUN Director of Web & Technology Services, Student Affairs. husband, father, gamer, part time aviator, fitness enthusiast, Apple fan, and iguana wrangler.

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

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.

 

 

 

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!!

 

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

 

 

 

 

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.