Tag: case study

Categories
Technology

My EDUCAUSE 2013 Mega Post

One the things I try to do when I attend conferences is to make a detailed record of all the sessions I attend, with the exception of keynotes, which tend to get really good coverage from other folks.  I live blog the events as I attend them, which hopefully helps those who committed to other sessions, and then I do one of these “mega posts,” which summarize all the posts I attended.  Based on my itinerary, 2013 seems to be the year of big data and analytics.  I’m willing to bet a lot of my fellow attendees will agree 🙂

I’ve been in higher education for just over seven years now, and somewhat amazingly, this was the very first EDUCAUSE event I’ve ever attended.  Why didn’t anyone tell me about this conference?  It was an extremely worthwhile event, at least for me…one of the meetings I had will likely save my division close to $50,000 each year!  That savings will go a long way toward providing students at CSUN with more and/or better services.  There were lots of great sessions to attend, with lots of smart folks sharing what they’re doing with IT on their campuses.  I’ll definitely be back next year.

Without any further ado, here’s my EDUCAUSE 2013 mega-post…please drop me a line and let me know if this helps you!

 

Friday, October 18 (last day of EDUCAUSE was a half day)

 

Thursday, October 17 (my busiest day)

 

Wednesday, October 16 (spent a few hours prowling the vendor floor and visiting with my accessibility colleagues)

 

Tuesday, October 15 (each session was a half-day long)

 

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

 

 

 

%d bloggers like this: