Accessibility Technology

A Digitally Inclusive Future for Canada’s National Broadcaster

Presenters:  Patrick Dunphy accessibility specialist from the CBC

@PatrickDunphy | Co-lead #a11yTO with George Zamfir (@goodwally) and Billy Gregory (@thebillygregory)

This was my fifth session at the CSUN conference on Friday, March 6.  I’m always interested in hearing about how very large – particularly media companies – approach their accessibility remediation efforts.

What is CBC?

  • We’re a publicly funded Canadian radio, tv, online

2020 Strategy

  • Intensify relationship with citizens with disabilities
  • 13.7% of Canadians self-identify as having a disability (3.8 million)
  • However, no captions for recent olympic coverage
  • Silver tsunami is coming…

We’ve Been Busy!

  • Launched to gather feedback on what’s wrong
  • GAAD:  Global Accessibility Awareness Day
  • 4-part learning series
  • Accessibility inquiry form for intake
  • Developing an internal knowledge base (Confluence)
  • Accessibility task force (July 2014) got everyone involved:  IA, design, SME, QA, PM, Apps, Architect, Content, UX, management
  • Jumped into agile in a big way (which was not without it’s bumps)

In October 2014, We Committed to a 4-year Rollout Plan

  • We will make our digital content meet WCAG 2.0 AA standards by April 2018.  Digital operations is leading this effort, with 8 product teams using agile methodology.
  • We completed a gap analysis with The Paciello Group
  • Identified training needs
  • WCAG2.0 training for devs, designers, and QA analysts
  • Accessibility requirements identified for 3rd party vendors

Gap Analysis

  • Task force meets weekly
  • First, we reviewed 25 screens across CBC, CBCNews, CBCSports, CBCRadio, Network
  • Summary of gap analysis identified a range of issues likely to significantly affect the ability to interact with; lots of work had been done, and moderate level of effort would be required to get it up to scratch.
  • Screen reader training

Learning & Development Initiatives

  • Lots of checkpoints to think about what we want to get to, and narrowed it down into what was feasible
  • Onboarding process
  • Q&A webinars
  • Moderated forums
  • Printable cheat sheets
  • Code samples
  • Bi-annual training
  • External assistance




Accessibility Technology

The Digital Accessibility Maturity Model for Measuring Program Success

Presenters:  Tim Springer and Jason Megginson from the SSB BART Group

@SSBBARTgroup | View this slide deck online

This was my fourth session at the CSUN conference on Friday, March 6.  The CIA’s session yesterday referred to a different maturity model (the Business Disability Forum’s Accessibility Maturity Model), which piqued my interest and is why I’m here.  I’m beginning to think that the tagline for this conference should be “There’s a session for that.”

What the hell is a maturity model?

  • Defines organizational maturity level in addressing a business problem.
  • DAMM (Digital Accessibility Maturity Model) measures digital accessibility program maturity along a series of dimensions and aspects, to assign them to particular levels

The Digital Accessibility Maturity Model

  • The five levels of DAMM
  • Initial (chaos)
  • Managed (pockets of expertise across the enterprise)
  • Defined (across the enterprise)
  • Quantitatively Managed (repeatable, metrics lead change)
  • Optimizing (reflective, feedback system)
  • DAMM is not a roadmap, but an ongoing business process
  • More maturity != greater conformance
  • Other models require that you must reach a higher level of compliance to achieve a higher CMM level
  • A mature org with a clear grasp of digital accessibility concepts may determine not to conform to a higher level of accessibility

Why a CMM based Maturity Model?

CMM model process improvement adds value to other business areas:

  • Fewer defects
  • Better on-time delivery
  • More likely to be on budget
  • Increased Quality Software Management Productivity Index

There are 10 DAMM Dimensions…

1. GRC (Governance, Risk, Compliance)

  • Looking for higher levels of organizational ownership
  • Aspects:  organizational ownership, governance policy, risk management, compliance program, accessibility program office, monitoring, reporting, record keeping
  • Artifacts:  Org chart, accessibility monitoring plan, accessibility program roles and responsibilities, accessibility project management plan, risk prioritization model, accessibility coverage questionnaire

2. Communication

  • Aspects:  Program comm, internal comm, market comm
  • Artifacts:  Public comm plan, org-wide compliance statement

3. Policy and Standards

  • Aspects:  accessibility policy and standards
  • Artifacts:  digital accessibility policy (some laws require this), technical standards

4. Legal

  • Aspects:  Regulatory process
  • Artifact:  regulatory calendar, regulatory filings, VPATs GPATs (in conjunction with communications)

5. Fiscal Management

  • Aspects:  budget, ROI
  • Artifacts:  central APO budget (persistent from year-to-year), LoB digital accessibility budget guidance, LoB digital accessibility budgets

6. Development

  • Aspects:  development artifacts, roles and responsibilities, user acceptance, pattern library
  • Artifacts:  lifecycle roles and responsibilities, development artifact guide

7. Testing and Validation

  • Aspects:  accessibility training, infrastructure, accessibility testing artifacts
  • Artifacts:  Accessibility testing plan, usability testing, user group profiles, pilot program, assistive technology catalog

8.  Support and Documentation

  • Aspects:  support process, issue handling, accessible documentation
  • Artifacts:  features document, resolution policy, issue submission form

9.  Procurement

  • Aspects:  solicitations, contracts, vendor governance, employee guidance
  • Artifacts:  3rd party compliance policies and reqs, ICT procurement contract template, ICT procurement policy, procurement accessibility email address

10.  Training

  • Aspects:  training, certification, job aids, internal communication, rollout strategy
  • Artifacts:  training plan, internal comm plan, training metrics and trends
Accessibility Technology

7 Lessons from Developing an Accessible HTML 5 Video Player

Presenter:  Dennis Lembree from eBay (previously with PayPal access team 2+ years)

@dennisl | @EasyChirp | @WebAxe

View the project on github

This was my third session at the CSUN conference on Friday, March 6.  I know PayPal has done a lot for accessibility, so this should be an interesting session.  Keyboard traps have historically been a big issue, I wonder if that will be covered here.  We shall see.  [UPDATE:  this was a really meaty presentation, glad I attended ]


Works on accessibility at eBay, previously at PayPal, Creator of @easychirp, creator of @webaxe

About the Player

  • Launched September 2014
  • Goals:  take advantage of HTML5 for video, controls, captions
  • Greatly reduce code weight and complexity while still supporting cross-browser/OS/device
  • Support captions (WebVTT format)
  • Options upon intialization:  captionsOnDefault (default is true), seekInterval (default is 10), videoTitle (default is play), debug (default is false)
  • Width adjusts to width of video element (minimum 360px)
  • Fully responsive version of the player by @LauraKalbag
  • Controls are toggles (checkboxes “under the hood”), which can be activated by the spacebar or enter key
  • Question:  is there a reason why captions are on the top?  This was a design decision.  Web VTT spec has a mechanism that tells where captions can be keyed.
  • Has a pure HTML5 range input slider for volume

Lesson 1: Don’t Need Dependencies

  • Developed without the use of any CSS or JS libraries
  • Code weight is very small; uncompressed and not minimized
  • CSS is 5k (mediaelementplayer.css is 24kb)
  • JS is 18K (media-element-and-player.js is 156kb)

Lesson 2:  HTML5 Elements are Becoming More Accessible

Lesson 3: Don’t Need Flash Backup

  • All modern browsers support HTML5 video element
  • Only IE8 doesn’t support it.  In that case, a direct link to the video can be provided
  • See your browser’s level of support

Lesson 4:  Mobile Has Great Support

  • iOS and Android support the HTML5 video element
  • They also support WebVTT captions
  • Custom controls of the video player are not used on mobile devices (bypassing all of Dennis’ code)

Lesson 5:  Browser Sniffing is Required

  • I REALLY didn’t want to deal with this, but I had to.  Why…?
  • There are several inconsistencies in support between desktop browsers:  display of range input in IE, coloring the progress bar in Firefox, support of the textTracks video property in IE, Firefox, and Safari (this was by far the biggest problem that I had)
  • Question:  does the MP4 container require the VTT hosted as a separate file?  Yes.

Lesson 6: Chrome by Far Has Best Support

  • None of the challenges of the project were experienced in Chrome
  • Chrome was used as the baseline browser for development
  • Chrome supports textTracks and WebVTT very well and renders HTML5 elements as expected

Lesson 7:  github is Great for Tracking Issues

  • Great for sharing code
  • Done in the development stage and now in the released stage
  • Make an enhancement request, log an issue or better yet, resolve an issue!
  • ..also for showing how successful the project is!  Been starred over 1,500 times


  • Limitations:  supports only one caption file and one caption type
  • Would be great to see mainstream browsers support HTML5 video better
  • Key enhancements:  localized text (internationalization), support for audio description
Accessibility Technology

Evaluating the Accessibility of your Website: New Resources and Tools

Presenters:  Shadi Abou-Zahra and Eric Eggert from the W3C Web Accessibility Initiative (WAI)

This was my second session at the CSUN conference on Friday, March 6.  Full disclosure:  I’ve had some involvement with these projects via the W3C’s WAI-EOWG group.

Overview of New Resources and Tools

  • WAI Eval Resources
  • WCAG-EM Report Tool
  • Eval Tools List
  • Eval Tool Features
  • auto-wcag Community Group

WAI Evaluation Resources

  • “Easy Checks” provides tips for anyone on how to analyze web pages for accessibility.  Shows simple ways to use browser toolbars.
  • “BAD” (Before After Demo) will show common errors and how to fix them in a web page that’s horribly inaccessible.
  • Involving Users in Evaluating Web Accessibility
  • WCAG-EM Report Tool is a guidance tool that is non-normative.  It is just one way that you can use to evaluate the accessibility of your web pages.  Shadi walked through the WCAG-EM Report tool to show how it works…it’s very useful for folks who are doing web site accessibility audits.
  • Web Accessibility Evaluation Tools List provides a filterable list of tools (paid, free, and open-source) that are available to help you evaluate web accessibility.  Vendors and developers can add their tools to this list.
  • Developers’ Guide to Features of Web Accessibility Evaluation Tools helpful to folks who are planning to procure software for web site evaluation
  • auto-wcag Community Group is a new way for anyone to come together to put together test cases for tool developers to validate their tools work.  You don’t have to pay to be a W3C member…it’s totally free to join this community.



Accessibility Technology

Choosing an Accessible UI Framework

Presenter:  Gerard Cohen from Wells Fargo, Kevin Kalahiki

@gerardkcohen | Slide deck at

This was my first session at the CSUN conference on Friday, March 6.  I’m getting off to a good start, definitely feeling better than last night.  My headache yesterday made me go up to my room about 4:00 PM, and I ended up sleeping until 10:00 PM, completely missing the reception.  D’oh!  I’ve got another full day of sessions, so let the coverage begin.  Every year, there seem to be more great sessions scheduled on the last day of the conference.

Choosing a framework is a serious decision, it’s something you’ll have to live with for at least a few years.  Ease of use, popularity, opinionated, customization, size, and of course accessibility are all considerations.  How do you know which one is accessible?

Frameworks that will be covered here

  • Angular.js
  • Bootstrap
  • Foundation Zurb
  • JQuery Mobile Framework

Other Topics Covered

  • Documentation
  • Forms
  • Tabs
  • Dialogs


  • Proper Labels / Descriptions
  • Keyboard Navigation / Focus indication
  • Color Contrast
  • ARIA (is it being used properly?)


  • Angular 1.4 developer guide, ngAria; has accessibility patterns documented
  • Bootstrap has a good accessibility page; skip to content, nested headings, etc.
  • Foundation has an accessibility page, but it’s a little slim.  It’s pretty much copy/pasted from Bootstrap, with links to some other resources.
  • JQuery Mobile does NOT have a specific accessibility page, but does have an “accessibly hidden labels” section.


  • Easy to get right – and wrong.
  • Error validation is typically customized because HTML5 validation (support) is lacking
  • Proper labels / Grouping, Focus indication, Color contrast, Error validation
  • Angular has a bad rap for accessibility documentation on forms.  Labels are not included on input fields by default.  However, a lot of work is being done with Angular Material Design.  Fields are not grouped together properly by default.  Required fields automatically show a color indication onFocus, but colors do not meet color contrast.
  • Bootstrap:  error validation needs to be handled, does require some weird markup, color contrast issues
  • JQuery Mobile:  their forms pass pretty much every check Gerard was looking for.


  • Criteria:  Keyboard interaction, focus indication, color contrast, ARIA
  • Tab key focuses active tab
  • Left/up for previous tab
  • Right/down for next tab
  • Arrow keys should cycle
  • Roles;  tabpanel, tablist, tab
  • States:  aria-selected
  • Properties:  aria-controls
  • Bootstrap (core) tabs:  arrow keys don’t work.  ARIA roles are done right, tabpanel is there, list of tabs is there,   Color contrast is also missing.
  • Angular.js:  doesn’t come with any built-in widgets, you rely on material design.  Documentation isn’t there.  Arrow navigation works, but it doesn’t cycle around.  Does not activate tab when selected.
  • JQuery Mobile:  was perfect…nailed it!
  • Foundation:  has NO focus indications, but basic keyboard interaction is there (a little pointless if you can’t see where you are.  Also, you need to press enter to activate tab.


  • Keyboard interaction, focus indication, color contrast, ARIA roles
  • Tabs should remain within the dialog itself, esc is expected to dismiss dialog, enter should submit the form.
  • Roles:  dialog, alertdialog
  • Properties:  aria-label, aria-labelledby
  • Foundation:  has a big note at the bottom that it is not accessible.  No roles assigned, tabbing doesn’t make it into the dialog.


  • Forms:  explicitly associate labels with inputs, group related fields with fieldset/legend, convey error state and description (each framework has classes to handle this)
  • Tabs:  use PayPal accessibility plug-in
  • Dialogs:  this is where I had to do the most work.  Cycle focus within dialog, focus should return to trigger
  • Body content should also wrap

 Future of Frameworks

  • None of the material design widgets will be released unless they are fully accessible
  • Foundation is starting from scratch, specifically for accessibility v 6 should be available in June
  • Next version of bootstrap is being refactored (Patrick Lauke from TPG is reworking this personally.)
  • Anything you can do to help is greatly appreciated!


%d bloggers like this: