Tag Archives: technology

Accessibility at the BBC

Presenter:  Ian Pouncey, @IanPouncey

(Be sure to look at Ian’s Feb 23 retweet of theVine video of a guitar playing with a dog drumming.  It’s awesome.)

This is the third presentation I attended on Wednesday, March 4 at the #CSUN15 conference.  Ian’s presentations have been entertaining in the past, so I’m looking forward to this one.

Ian shared a couple quotes from BBC higher-ups:

  • “Everyone deserves the best” quote from Tony Hall, BBC director General, 2013
  • Hugh Huddy quote on the iPlayer

BBC Accessibility Team

  • 3 people responsible for: training, standards & guidelines, techniques, framework support
  • Not responsible for accessibility of sites or apps.  We have 7,000+ content producers, our team would need to be enormous to cover all this!


  • Accessibility for web developers:  this is an online course that takes about two hours and shows how real people with disabilities use their products.
  • Introduction to screen readers:  one-day workshop that provides hands-on use of screen readers, including iOS and Android OSes.  It’s primarily for front-end developers.
  • Question:  is it for Jaws?  Yes, but if the users have NVDA, we provide guidance for them as well.
  • Question:  can you make this training publicly available (laughter ensued).  For the web developer course, we’d really like to, but we may not be able to for competition reasons.

Upcoming training

  • QA
  • UX
  • Product Management
  • Mobile application development

Standards & Guidelines

  • Mobile Accessibility
  • HTML
  • Assistive Tech

Mobile Accessibility Standards & Guidelines

  • Technology agnostic, but platform specific techniques
  • All have success criteria

HTML Accessibility Standards

  • Minimal set of expected standards for our products
  • Standards are unambiguous so there can be no arguing when we engage with content partners

 Assistive Technology Testing Guidelines

  • Currently for screen reader only
  • Not support guidelines
  • Showed a very long list of guidelines that they use for testing

Question:  How do you choose/define your “window of support?”  We have a standard approach for screen readers and browsers.  Generally, we use “current version minus one,” with an exclusion for some versions of Internet Explorer.

Question:  do you have any tools for automated testing?  Yes, I’ll discuss that shortly.

Standards vs Guidelines

A standard is:

  • Must or must not
  • unambiguous
  • Unambiguously testable


  • Should or should not
  • Must or must not that is:  open to interpretation; testing requires judgement

Anatomy of a well written standard

  • Short description:  a document must have exactly one H1 element
  • Rationale:  must be useful, i.e. “Users should be able to use the document’s <h1> to identify its main content.  Documents should have one main subject”
  • Examples
  • Testing Criteria:  Procedure, i.e. “Use WAVE toolbar or similar to generate a document outline, there must be exactly one <h1>”

Secret bit

  • bbc-a11y ruby gem

Standards vs Understanding

  • Understanding is more important than standards, but organizational awareness is more important than understanding
  • Goal is to enable people to do their jobs as easily as possible
  • We don’t want accessibility to be a checklist activity, but we realize that sometimes it does work that way
  • It should be embedded into everything we do so that the knowledge gets “locked in”

Accessibility Champions Network

  • Extends our team’s reach
  • Spreads knowledge and understanding
  • Our eyes, ears, and voice in products
  • Not just for developers
  • Don’t have to be an expert
  • Not responsible for accessibility
  • Shares knowledge

Benefits of being a champion

  • Additional training
  • Closer contact with accessibility team
  • Work with other teams
  • 10% time project
  • Prestige!  Fame!  Glory!
  • There will

Question:  do you do any assessments of the work the developers are doing?  Occasionally, but it’s often more about the frameworks and components that are used in a product.

Question:  How often to accessibility champions answer to their team?  It’s a new thing we’re starting.

UX:  Roles and Responsibilities

  • Visual design
  • Semantics
  • Markup and content order
  • Hidden content

Design is Critical

  • Development may not be the most important part of the project!  This one looked painful for Ian to say 🙂

Beyond Design & Development

  • Product Owners:  encourage training; make the accessible decision, not the easy decision; plan for testing with disabled user
  • Content producers:  understand alternatives, plan for audio desc, subtitling, etc.

Global Experience Language:  GEL

  • Similar to Google’s, but not as well maintained.  It’s a bit out of date
  • Showed an example of an overlay/carousel panel

Document design knowledge

  • Enable design iteration
  • prevents repeated mistakes
  • encourages evidence based desing
  • educates

Code Based GEL

  • Production quality code
  • White labelled
  • Acceptance tests included



The Implementation of PDF/UA and Standardized Access to PDF Content

Presenter:  Karen McCall of Accessibil-IT, Head of Quality Control and Training.  @accessibilit

This is my first post of the CSUN 2015 conference, and the first presentation I attended on Wednesday, March 4 at the #CSUN15 conference.  I have a particular interest in this topic because the latest round of accessibility remediation and content updates my web team and the folks I work with at CSUN are addressing is the vast number of Word and PDF documents posted on the CSUN web site.  I’ve also read a little bit about the PDF/UA ISO standard (thanks @WebAIM list serve!) and am interested in seeing how – or if – this has any impact on the work my colleagues will be doing where “the rubber meets the road.”

Accessibil-IT swagAccessibil-IT folks handed out some “accessible IT swag” just before the presentation:  a key-shaped USB stick.  Nice 🙂  They claim it’s the best swag offered at the conference…we’ll just have to see about that!

This session is divided into two parts:  brief powerpoint slide presentation, then a demonstration of an Adobe Acrobat Pro document that is PDF/UA compliant with Jaws screen reader.

Karen has been working with Adobe PDF for about 15 years, and has written books, given training sessions, contributed to the standard and much more during that time.  She’s also a Canadian delegate to the standards committee.  Contributes to both user experience perspective and technical standard.

This is written into the newly published US section 508 refresh:  documents will conform to all Level A and AA success criteria in WCAG 2.0 or ISO14289-1 [PDF/UA-1].

PDF Accessibility 101

  1. if a PDF is not tagged, it is not accessible
  2. Just because a document HAS tags, doesn’t mean it’s accessible
  3. Read out loud text-to-speech tool is NOT A SCREEN READER

What is PDF/UA?

  • Initiated by AIIM (association for information and image management and adobe systems in 2004
  • Responsible for establishing a set of standards for crating accessible PDF
  • A technical standard for software developers
  • An implementation strategy for achieving accessibility within a PDF
  • designed around the same barrier-free principles behind the methodology of WCAG

Why do we need PDF/UA?

  • To achieve a reliability of expectations from one PDF to the next
  • PDF/UA success criterion are broken down into three parts:
  1. File conformance [ISO 14289-1]; file conformance [ISO 32000-1]
  2. Reader conformance
  3. Viewer conformance

Having a published standard will make machine-readability much easier for vendors like Google, Microsoft and others (think creation & conversion).  Human QA is still going to be needed, but to a somewhat smaller extent.

Question:  will book publishers be required to adhere to this standard?  Not at this time, but we are notifying publishers that there actually IS a published international standard now.  This is part of the reason why we come and give presentations like this at #CSUN15.

Question:  Does the standard cover forms?  Yes, but there’s a distinction between XFA forms and forms created Adobe Acrobat.

As of today, NVDA is currently the only AA-compliant PDF/UA reader.

What’s Different with PDF/UA?

  • It provides developers a framework to build accessibility into their application or output file from the start
  • It eliminates perceived “best practices” or “user preference” from organizational document accessibility practices
  • It’s based on semantics and established document authoring logic

PDF/UA compliant documents will provide a more consistent user experience, which is important for users

  •  Provides a prescriptive PDF interaction model which addresses a broad range of disabilities and facilitates the use of many adaptive technologies.
  • Leverages the applicable WCAG principles for the best in general usability.

Question:  Does it allow for reflowable text?  Yes.

Question:  How does it provide for tagging diagrams?  There is an implementation guide published by AIIM that describe how to do this.  I recommend you have a look at the “Matterhorn Protocol,” which provides a checklist that describes how document remediators should do this.  The PAC (PDF Accessibility Checker) does something similar (note:  PAC developer is xYMedia, their web site is in German) .  Neither of these tools eliminate the need for human quality assurance.  A comment from the audience highlighted the usefulness of the PAC for people who are new to PDF remediation.  The PAC tool is not itself accessible with JAWS (the devs know about this and are working on it), but it’s actually a great “in your face” way of showing you mistakes in the document.

Demonstration of a PDF/UA-compliant document showed some of the useful features for end-users.  This included use of keyboard shortcuts for document navigation by headers, images, links, tables and more.