Tag: technology

Categories
Accessibility Technology

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!

 

Categories
Accessibility Technology

Scaling Web Accessibility from Specialist Niche to Business-as-Usual

Presenter:  Jonathan Hassell from Hassell Inclusion

@jonhassell

This was my second session at the CSUN conference on Thursday, March 5.  Jonathan spent some time talking about himself and his many awards and accomplishments, notably the UK accessibility standards, BS8878.  People in attendance received a copy of the first chapter of his new book, which is on sale for $50 here at the conference.  http://openinclusion.com/book

The Good News:  You’re in Demand

  • Large companies are taking accessibility seriously and are having trouble finding the right people to hire
  • Companies are looking for people “with the right skill sets”

What are the right skill sets?  What to do?

  • Technologies of course (WCAG 2.0, WAI-ARIA, etc.)
  • But the bad news is that nobody makes it on their own
  • You spent time learning good stuff, brought value to the organization, but maybe you’re not having the impact you want to have.  What to do?
  • Engage everybody in your organization.  You have to build the internal ecosystem.
  • Doing it all yourself will burn you out, which is bad for you and your organization
  • Know how to make collaboration successful
  • Prepare for your exit – the organization must be able to succeed without you

Expand

  • What is it that YOU want?
  • Who needs to be motivated for you to get what you want?
  • How will you convince them to spend time on accessibility rather than something else?
  • Convert the guy at the top, or everyone
  • Winning is good
  • Choose your emphasis depending on what your organization does
  • Work out what to say to who

Embed

  • Do staff and policies facilitate or inhibit accessibility?
  • You need strategy people batting for you, and they need to be effective delegators
  • Who is responsible for accessibility?
  • Split responsibilities up by job roles
  • Train people for their responsibilities, not everyone else’s
  • Train for things that don’t change, outsource advice on edge cases
  • Keep QA in-house, use external auditors
  • Don’t get too dependent on externals
  • Organizational web accessibility policy should be part-and-parcel of key policies (not it’s own standalone document – which nobody will read anyway)
  • Start with what is most strategically valuable
  • Governance needs to apply to all channels that you’re using
  • Categorize what’s most important to you and your users; how easy will it be to make them accessible.  Concentrate on enablers and pillars.
  • Be relaxed with innovators
  • Benchmark:  where you are, where you want to be, costs/benefits of getting there.  Where will you get the most value for money

Enable

  • Fix problems in your process; compliance is not sustainable!
  • Process needs to allow you to efficiently deliver product; also needs to be flexible, cost efficient
  • Effort and testing are often overlooked/underestimated in planning

Effect

  • Keep things going by capturing ROI
  • Leave a legacy by proving the worth of the work
  • Difficult to prove the value of the premium until you file a claim
  • Get good press coverage, it’s worth a LOT
  • Ability to recruit a diverse work force
  • Minimize customer complaints (make evangelists, not complainants)
  • Start counting:  analytics matters!

 

 

Categories
Accessibility Technology

Real-Time Conversations: From TTY to Real-Time Text (RTT)

Presenter:  Aaron Bangor, Lead Accessible Technology Architect, AT&T Corporate Accessibility Technology Office

aaron_bangor@labs.att.com

This is the fifth presentation I attended on Wednesday, March 4 at the #CSUN15 conference.  I’m slowly getting worn down here :-/  I’m personally interested in this session because of some recent development efforts me and my development team at CSUN have had with our National Center On Deafness (NCOD).  Not exactly sure what AT&T has on tap here, I hope it’s relevant.

Where are we with making voice communications accessible to the Deaf and Hard of Hearing community?

  • Voice communications used to go through the phone network (POTS – Plain Old Telephone Service), but the underlying circuit switching really has not changes much.  Now it mostly goes through the Internet, but the need to communicate in real-time among individuals has not changed
  • In the mid-1960s, the then-old teletype machine was adapted to create the TeleTypewriter (TTY)
  • TTY’s purpose is to provide non-voice service (aka data) over a phone line.
  • Reviewed the basics of a TTY call, including some info on how TTY work over cellular networks now.
  • 1,400 Hz and 1,800Hz tones can carry text.

Benefits and Drawbacks

  • Works well for people with hearing and speech disabilities
  • Interoperable
  • Text-based
  • Real-time
  • Interactive
  • Intermixed with voice channel
  • BUT…it’s slow
  • Turn-based/half-duplex
  • Resource intensive from a network resource perspective
  • Dedicated network resource needed for wireless
  • Requires separate assistive technology not commonly used by telephone customers without disabilities

 TTY is not

  • Instant messaging
  • Email
  • Over-the-top messaging (WhatsApp, Kik, etc.)
  • Video conferencing
  • Text messaging (SMS)
  • These are all services that can – and are – being used to communicate instead of using a TTY on a voice call

 TTY Meets the Internet Protocol

  • TTY tends to work best on a wired connection with QoS, not so great when using lossy codecs
  • There are challenges to doing this (like there was going from Standard Definition to High Definition TV)
  • Packet loss, Echo Cancellation, voice-optimized compression techniques

What is Real-Time Text, Benefits and Drawbacks

  • IP/Data, not voice
  • Lightweight
  • Less sensitive to packet loss
  • Standards-based
  • Conversational, real-time
  • BUT…it has limited adoption to date (mostly Northern Europe, not directly interoperable with legacy TTYs (internetworking function needed)

RTT is where we’re headed

  • Endorsed / recommended by many areas
  • FCC Emergency Access Advisory Committee (EAAC)
  • National Emergency Number Association (NENA); next-gen 911
  • US Access Board’s information and communication technology (ICT) standards and guidelines
  • RTT is an accessible technology that does not require a 3rd party piece of hardware to work

Are we there yet?  Not Really…

  • Much work needs to be done to build a robust, accessible service that also does not leave anyone behind
  • Network changes required to support RTT
  • Interoperability between RTT implementations (standards-based)
  • Software changes for IP phones and wireless handsets
  • Changes to ensure legacy TTY internetworking; network gateways between IP and legacy networks
  • Points of connection between legacy equipment and VoIP networks

Final Thoughts

  • TTY was a great engineering solution in its day, but it was designed for a type of technology that is disappearing
  • RTT is more user-friendly
  • Takes advantage of newer network technologies
  • Builds accessibility into the service, not requiring separate equipment
  • Opens up possibilities for all users to interact over the “phone” in more creative and expressive ways because it will be built into phones, not via separate hardware
  • It is the essence of Universal Design

 

 

Categories
Accessibility 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!

Training

  • 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

Guideline

  • 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

 

 

Categories
Accessibility Technology

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.