Tag: csun13

Categories
Accessibility Technology

The CSUN 2013 Web Track Mega Post

Greetings, fellow web accessibilistas!  (not to be confused with accessiballistas, the little-known and even less-documented accessible siege engine of yore).

As you may have gathered if you followed my live blog posts a couple weeks ago, my interest in attending the CSUN 2013 conference was almost exclusively web-related.  Now that it’s been a couple weeks and I’ve had some time to reflect, I figured it would be a good idea if I consolidated everything into one mega-list.  This year, there were several times when I wish I could have been in two places at once.  Hopefully this gives you a pretty representative sampling of what was on offer web-wise this year.  Follow me @paulschantz for more web-related topics, including accessibility, project management, web development and design philosophy, thoughts on working in higher education, bad clients, off-color humor, and other ephemera.  Enough self-promotion…on with the list!

Pre-Conference Seminar:  Google Accessibility

Day One:  February 27, 2013

Day Two:  February 28, 2013

Day Three:  March 1, 2013

Categories
Accessibility Technology

Accessibility on the BBC Olympics Website

Presenters

 

INTRODUCTION

  • About the project
  • Accessibility at the BBC
  • Challenges
  • Desktop and tablet
  • Video
  • Mobile
  • Lessons learned

 

First truly digital Olympics, a very ambitious project

  • Aspiration was that it would have same impact as Coronation did for TV in 1953
  • Built around sports domain, a page per domain item; all were interconnected
  • Showed slide with content chunk breakdown
  • Lots of other components as well (comparison of performances, Twitter, promo, medalists, etc.)
  • Index page for everything (countries, sports, events, athletes)
  • All dynamically updated in real time using data from the Olympics Broadcasting Service
  • Most of it on mobile and even TVs
  • Usage and stats:  37 million UK browsers (66% of UK online adult population, and other very large numbers

 

ACCESSIBILITY AT THE BBC

  • Long history of accessibility
  • BBC Trust and charter
  • Lead by example (both internal and external)
  • License fee (we’re a public service, we answer to the public)

 

CHALLENGES

Accessibility consultant challenges

  • Size (web, mobile, video)
  • Standards and guidelines
  • Training
  • Ownership and responsibility (2 people were working full-time on accessibility at the BBC at the time)

Developer challenges

  • Size
  • Immovable deadline
  • 17 day event
  • Huge audience
  • High profile
  • Real-time data
  • Up front design
  • Lots of javascript
  • Multiple teams

 

DESKTOP AND TABLET

  • Accessible from the start
  • Speak to specialists early
  • Training – screen readers, WAI-ARIA
  • Research best practices
  • Set up a support network (made sure our work was peer-reviewed)
  • Front-end devs create the UI before integration
  • Brainstorm multiple solutions / Prototype / Iterate
  • Feedback issues early
  • Agile build and test (2 week sprints with prioritized backlogs)
  • Component library

PAGE TEMPLATES

  • HTML5 doctype
  • Lang attribute
  • Skip links
  • Unique title
  • Unique H1
  • WAI-ARIA landmark roles

 

Open Standards and Progressive Enhancement Made this all possible

  1. Content
  2. HTML and WAI-ARIA (hierarchical heading structure, used HTML5 elements with care, don’t duplicate links, code tables and forms correctly, etc.)
  3. CSS (take care with display:none, Focus as well as hover, font size +2, don’t use !important, etc.)
  4. JavaScript and HTML (feature detection, valid JS generated HTML, update state labels, no keyboard traps)
  5. CSS for JavaScript (contextual CSS body=”js”)
  6. WAI-ARIA for JavaScript (keep users informed, manage focus, implement keyboard controls, etc.)

 

ISSUES WE FIXED

  • Color contrast
  • Over-complicated markup (even if semantically correct, could be cluttered when uttered)
  • Broken navigation when resized
  • Favorite button
  • Keyboard inaccessible video clips
  • Unexpected keyboard controls
  • Keyboard trap (in a twitter module with infinite scroll)

 

ISSUES THAT GOT RELEASED

  • Color only medals
  • Country page content order
  • Indistinguishable links
  • Info graphics
  • Auto suggest not read out (jQuery live regions didn’t work at the time)
  • Auto refresh (built by external vendor)

 

VIDEO

Interactive Media Player

  • BBC Sole rights holder
  • 24 live streams
  • Flash player (being able to switch channels while within the player was key)
  • Fully immersive “lean back” experience

Approach

  • Tender and contract
  • BBC Standards and Guidelines
  • Requirements and User Acceptance Criteria
  • In house testing
  • User testing with disabled users
  • Document for player UI:  IVP Interface – Tabbing and Screen Reader Support v2

Requirements

  • No autoplay
  • No background image interference
  • No flashing
  • Contrast
  • Text size

Choice was important for IVP (Interactive Video Player)

  • Alternative was provided that used HTML controls
  • What do we call it?  Accessible, Alternative, or something else?
  • 3 links above HTML version (Default player, Alternative player, Pop-out player)
  • “Choose how you watch” text was an H2
  • Accessible tooltips provided
  • Help link beneath players
  • Separate play / pause buttons, or single switch button?
  • HTML controls didn’t work in full screen mode

Access Services

  • Live “enriched commentary fo the Opening Ceremony
  • Audio only on TV
  • Audio and video via the web
  • Subtitles for BBC One, Two and Three
  • No controls over the other streams

Compromises

  • IVP not as accessible as planned
  • Immovable deadline
  • Decided not to promote it as accessible

We offered

  • Mobile web site
  • Apps for Android 2.2+ and iOS5+ (Offline storage, Personalization)
  • Shortcut on Blackberry
  • Live and catch up video

The Challenge

  • Expertise and experience
  • Standards and guidelines
  • Testing and evaluation

BBC Mobile Accessibility Guidelines

  • Technology agnostic standards and guidelines
  • HTML, iOS and Android techniques
  • Evaluation criteria

Approach

  • Use standard not custom components
  • Progressive enhancement
  • Follow platform specific guidelines

Structure

  • H1 – H6
  • Landmarks
  • Data tables

Alternative

  • HTML:alt
  • Android:contentDescription
  • iOS:  UIAccessibilityLabel / Trait / Hint

Changes of state

  • Tab panel
  • Open / close

Announce Changes

  • Update the alternative
  • Visible changes

Compromises

  • Pinch / zoom
  • Assets – arrows
  • 3rd party content (didn’t know how compliant it’d be)

Lessons Learned

  • Documentation
  • Sign off at UX
  • A variety of testing
  • Progressive enhancement is key
  • Easy to introduce issues at all levels
  • 100% accessible is not realistic – need to prioritize

 

QUESTIONS

  • Have the accessibility processes learned here been sustained and ongoing?  Yes, it has raised awareness in a really big way, especially with mobile.
  • What tool for evaluation?  Some automated testing was done, but no enterprise tools in-house

 

 

 

Categories
Accessibility Technology

Integrating Accessibility into Corporate Culture

Presenters

  • Tony Olivero – Humana – @TonyOlivero
  • Glenda Sims – DeQue Systems (nee University of Texas) – @goodwitch
  • Denis Boudreau – Deque Systems – @dboudreau

Download the presentation:  goo.gl/xHjzM

 

THE HUMANA STORY

  • Big insurance company with millions of members
  • Medicare plans are their largest business area
  • Accessibility is a fundamental right of our members – our legacy systems require some work to be accessible

 

Wanted to get a “dream team” of accessibility experts to help Humana get there.  A key question for them was:  How can we document things in a way that our developers know how to bake accessibility into our development processes, so that our web sites are accessible?  (See what I did there by making the question into an agile story?)

They’ve had a lot of success with getting the word out.

 

Glenda – ACCESSIBILITY TEXAS STYLE

  • Current Texas State Law = 508 (almost – instead of letters, they use numbers.  Also, captioning is “on request”)
  • University of Texas #a11y = 508 (after 508, then moving toward WCAG)
  • Did not create a lot of documentation initially
  • When working for Deque, she found that most of her financial customers wanted to have documented guidelines.  Consistency in application of guidelines is important, but there isn’t a single monolithic place where you can go to get “THE ANSWER.”
  • Settling on how the organization does WCAG2.0, but creation of custom a11y guides.  Pearson, Penn State, and UT have one, for example.

 

Denis – WCAG 2.0 IN THE FIELD

  • Often, guidelines are viewed as not adequate for their organizations’ needs (“One size does not fit all”)
  • How can an organization managing multiple web development teams over as many development projects make their entire web presence consistently accessible, when no one agrees on what must be done, and how?
  • WCAG 2.0 leads to various interpretations…when reading it without context, it doesn’t necessarily make sense.

 

REINVENTING THE ACCESSIBILITY WHEEL

  • Re-read WCAG2 guidelines, felt that he needed to analyze what it actually meant.
  • Created a “WCAG2 filter” to develop a contextual interpretation of WCAG2 so that people would actually use it.  This filter made communicating with stakeholders much easier.
  • Unfortunately, our “filtered” version had a different numbering system than WCAG2, which made mapping issues uncovered by evaluation tools somewhat difficult.

 

ROLES AND RESPONSIBILITIES BREAKDOWN

 

NORMATIVE AND INFORMATIVE PARTS OF WCAG2.0

  • It’s a guideline, not a requirement

 

HAUS – HUMANA ACCESSIBILITY AND USABILITY STANDARD

  • This is Humana’s interpretation of WCAG2 standard, documented as described above.
  • Example:  SC 1.4.1 – Use of Color:  color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.  (Level A)
  • HAUS 4.1 – Use of Color (went through the 4 rules that Humana uses internally to interpret SC 1.4.1).
Categories
Accessibility Technology

OpenAjax Accessibility Evaluation Library 2.0

Presenter

Jon Gunderson – University of Illinois, Urbana Champaign

More info here

 

Jon talked about the OpenAjax Evaluation Library.  He opted for slides with LOTS of bullet points on each page 🙂  I generally don’t enjoy sitting through tool walk-throughs, but this particular one interested me due to my awareness of Jon’s publishing of a list of “most accessible university web sites.”  From what I could see, this is a pretty powerful and flexible browser-based evaluation tool.  I must confess that I have little knowledge of the breadth of what these tools offer.

 

TOOLS THAT MEET DEVELOPER NEEDS

  • Open Source so rules can be customized to individual or organization priorities and needs
  • JavaScript library can be used in both browser and server based tools
  • Help devs understand the benefits to people with disabilities
  • Help devs understand accessibility by telling them what needs to change rather than what was violated or failed
  • Make it easy to filter rules and evaluation results
  • Provide summaries of evaluation results
  • provide support for manual checks
  • provide links to resources that can help devs underand and implement accessibility

Support Standards

  • WCAG2
  • ARIA landmark tech
  • ARIA widget tech
  • HTML 4 and HTML5 markup for accessibility

 

PURPOSE OF OPENAJAX ACCESSIBILITY LIBRARY, RULESETS AND RULES

  • Understanding of rules being used to evaluate accessibility
  • Understanding of rules leads to understanding of coding practices for accessibility
  • Understanding coding practices leads to better understanding of WCAG 2.0, 508, etc.

 

CHALLENGES OF THE DYNAMIC WEB FOR EVALUATING ACCESSIBILITY

  • Dynamic Content
  • Web Widgets
  • Dynamic Styling
  • ARIA
  • Keyboard support

 

MEETING THE CHALLENGES OF WEB ACCESSIBILITY EVALUATION

  • Live DOM info (analyzing HTML code is not enough anymore; content, elements and attributes added or deleted through scripting)
  • Computed CSS (color contrast analysis, determining visibility  of content to AT and visual rendering)
  • UI event handlers  (mouse, keyboard, click, drag events)

 

OPENAJAX EVALUATION LIBRARY

  • Evaluation Library -caches accessibility info of the DOM:  elements, attributes, event handlers, runtime CSS properties.  Executes the rules of a ruleset on a DOM, creates evaluation results:  WCAG2.0, Rule categories, element types…, Support internationalization.
  • Ruleset Features – required rules, recommended rules, basic rules
  • Rule Features – messaging about what to “change” rather than what “failed.” Rule category (form control, images, landmarks, headings, links, widgets), WCAG 2.0 success criteria, How does the feature help people with disabilities, techniques for satisfying the rules, manual check procedures, links to other information.

 

Jon demonstrated the tool with Firefox on www.ticketmaster.com

  • Sidebar shows a summary of the rule results
  • Beneath that are the elements themselves arranged in a grid
  • You can create your own ruleset if you want to
  • Showed the view menu, which is a list of rulesets you can select
  • Showed the preferences panel

 

Jon demonstrated AInspector menu in Firebug toolbar

  • QUOTABLE QUOTE:  “I’m making this tool for developers who want to do the right thing and move accessibility forward”
Jon showed a slide that mapped out the conceptual model behind the OpenAjax Alliance Accessibility Evaluation Library
STATUS OF THE LIBRAY AND TOOLS
  • Evaluation library 95% of the infrastrucut for eval and filtering resulte in place
  • Rulesets
  • Rules :  currently about 70 rules, want at least one rule for every WCAG
  • Tools using Library (OAA Accessibility Extension for firefox, AInspector for firebug, java-based servier utility based on HTMLUnit technology

 

PLANS FOR THE FUTURE

  • Functional accessibility evaluator (FAE) 2.0
  • Develop Coding practices resources
  • Build or support other people in building toolbars for other browsers
  • Ruleset 3.0 Features
  • Looking for volunteers and collaborators

 

QUESTIONS (some good ones were asked)

  • Where do we get the extension?  Links will be provided later in the presentation.  However…it’s called the “OAA (Open Accessibility Alliance) accessibility extension” and is available via Google Code, but will be available via Firefox plug-in store in a few weeks.
  • What if I don’t agree with your rulesets?  Can I modify them?  Yes, it can be done…I’ll show you how to do that.  That’s why we have this as an open source project.  We want to see more developers join in and contribute.  If you think you can develop the greatest ruleset ever, then this project can allow for this.
  • Where do you edit the rulesets?  It’s in the source code right now (JSON objects).
  • How useful is this tool for QA?  UI central IT people have been using it for a while now.  Comment from a user:  “Of all the tools we’ve used, this is the one that got it right.”
Categories
Accessibility Technology

Responsible Design: Accountable Accessibility

Arrived 10 minutes late, so

Bill Gregory – CGI – @thebillygregory

As a web developer, I took on responsibility for coding accessibility into my projects

When good enough stopped being “Good Enough”

  • Spent more time planning code up front, which lead to less time fixing later
  • Questioned everything on the page, made sure it was documentes
  • Wireframes became my recipe, I refused to  cook without them
  • Always assumed at least SOME level of accessibility

Own your code

  • Real lessons in teh stuff you did wrong
  • Every gbug could be a chance to learn something you didn’t know before

 

Top 10 things I can do that I have complete control over

  1. Semantic mark up
  2. ARIA landmark roles
  3. Lists and the many ways we can use them
  4. Skip links
  5. Focus
  6. Headings
  7. Forms and labels
  8. Alt text
  9. Hidden text
  10. Testing

 

QUESTIONS

How do you approach a dev when they come to you to learn “after they’ve already done everything?”  When baking chocolate chip cookies, you bake the chocolate chips into it.  If you add them afterward, it’s not a chocolate chip cookie, it’s a cookie with chocolate melted on top of it.

Missed a few questions ’cause I was listening and not typing…sorry!

 

%d bloggers like this: