Category Archives: Accessibility

Posts about Accessibility, yo

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 ]

Introduction

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

About the Player

  • paypal.github.io
  • 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  http://caniuse.com/#feat=video

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

Improvements

  • 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

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

  • www.w3.org/WAI/eval/
  • “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.

 

 

Choosing an Accessible UI Framework

Presenter:  Gerard Cohen from Wells Fargo, Kevin Kalahiki

@gerardkcohen | Slide deck at SlideShare.net

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

Criteria

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

Documentation

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

Forms

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

Tabs

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

Dialogs

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

Solutions

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

 

Revised Maturity Model: Case Study of the CIA

Presenter:  Benjamin Wilson from the CIA

This was my sixth session at the CSUN conference on Thursday, March 5.  I don’t think I’ve heard about a maturity model in the accessibility arena yet (they’re fairly common in IT), so I expect this presentation to be educational.  Frankly, I’m a little surprised there are so few people in this session.

Comes to this from a project management, change management and IT perspective.

Why is the CIA Here?

  • Primary goal of the agency is to provide as objective a perspective of the world as we can.  We try to avoid groupthink as much as possible.
  • Goal:  we want to be the Employer of Choice in the Intelligence Community for People with Disabilities
  • Goal:  employees with Disabilities have Independent Access to the information and data needed to accomplish their mission.

It takes 10 years to make culture change, and you should always consider that you’re in year 5

What is a Maturity Model?

Change Management

  • Management:  is there managerial buy-in and commitment to accessibility?
  • Pervasiveness:  how thorough is accessibility being applied in the organization?
  • Competency:  is workforce seeking competency in accessibility and disability awareness?
  • Adoption:  is the workforce actively adopting common tools and solutions?
  • Socialization:  is there employee buy-in and commitment to accessibility?

Capacity Levels in CMM

  • Incomplete > Performed > Managed > Defined

Business Drivers to Change Management

  • Senior commitment
  • Understanding
  • Awareness
  • Stakeholder engagement

2014 Accomplishments

  • CIA Accessibility program chartered
  • New accessibility policy
  • Leadership outreach (CIO annual conference, vendor’s quarterly, DAAC 2014)
  • Piloting processes
  • Communication

Standards & Guidance

  • Organization Process Definition
  • Organizational Training:  AT demos, disability awareness, developer training, IT support training
  • CIA Accessibility Standards:  WCAG 2.0 AA
  • Risk management for remediation:  scoring of applications on a Likert scale of 1-5; a 4.4 indicates a functional level of accessibility.

Programmatics – Key Process Areas

  • Organizational Process Performance
  • Organizational Performance Management
  • Risk Management
  • Acquisition:  vendor self-assess, agency audit contenders
  • Development:  self-assess, report, selective audit
  • Service Delivery
  • Annual report to executive director
  • Business process studies:  2013 accessibility, 2014 improvement of RAS

Acquisition/Development/Service Delivery

  • Objectively evaluate processes and work products
  • Provide Objective Insight

 

 

 

Accessibility in an Agile World

Presenters:  Jesse Hausler and Cordelia McGee-Tubb from Salesforce.com @jessehausler@cordeliadillon

This was my fifth session at the CSUN conference on Thursday, March 5.   Interested in this session because of my home institution’s use of Oracle/PeopleSoft, and I expect this session may provide an interesting counterpoint to that platform.

How Agile Fails Accessibility

  • Decentralized product ownership
  • Teams control their own backlog
  • Balance: bugs/accessibility
  • Balance:  feature enhancement / Enhancements
  • Separate accessibility features; mountain of accessibility debt
  • Unless a proper system is put in place, accessibility – under agile – will always take a back seat to the creation of new features

Executive Support

  • “The email” is not the solution.  It can’t do the work that needs to be done.
  • Executives remove blockers and help us build an environment in which accessibility can thrive

Building the Environment – Culture

  • Gain allies and raise awareness.
  • Build the base of passionate people.
  • Spread knowledge about accessibility
  • Build empathy through examples
  • Frame accessibility through your company’s core mission
  • Make it contagious (get other people talking about it)
  • Embed on a scrum team:  teach how to ship accessible features, learn at a micro level how agile works at your company.
  • Knowledge of your company’s brand of agile
  • Success building an accessible feature
  • Prove to the team that it’s not a big hurdle
  • Allies in UX, scrum leadership, development, and quality
  • Path to embed on another, larger, more influential team
  • Create an award that recognizes excellence; publicize winners, generate incentive to build accessible

Tools

  • Create reusable components:  use your contacts to join the appropriate scrum team, guide them toward the development of accessible components
  • 3rd party components:  know which ones are used, gauge level of accessibility, catalogue functionally equivalent alternatives for inaccessible ones, work with stakeholders to enlist accessible alternatives
  • Grassroots marketing campaign:  dropdown / throwdown poster was a classic (lots of great comics in this preso)
  • Take advantage of redesigns:  product redesigns are common, be prepared with a set of accessible, reusable components, beware of redesigns (they could pull out good stuff)
  • Testing Framework
  • Quality Engineering does not normally include accessibility as a traditional part of quality testing.
  • Automation is key to accessibility; build test automation that is specific to your environment.  Opt everyone in, automatically issue test failures where possible, test for patterns that indicate accessibility bugs, perform manual spot checks, track everything.
  • DOM test the simple things (WAVE-testable stuff)

Process

  • How does your company implement a new process?
  • Develop a plan:  problem statement, teams/groups impacted, proposal detail, tracking / success metrics, exception policy, release sign-off process, communication plan
  • Get an executive sponsor:  their main job is to believe in your idea.
  • Example meta process:  define problem > ID impacted parties > engage forum (present proposal, gather feedback) > go/no-go > re-socialize revised proposal, get alignment, final buy-in > go/no-go > visibility to executives > communication and rollout

Summary

  • Cultivate Support
  • Provide Good components
  • Leverage your test framework
  • Institute process change
  • Keep it going