Author: Paul Schantz

CSUN Director of Web & Technology Services, Student Affairs. husband, father, gamer, part time aviator, fitness enthusiast, Apple fan, and iguana wrangler.

Categories
Accessibility Technology

Oh, Canada? An Overview of Accessibility in the Great White North

This is my fourth session from the second day at the CSUN conference.  This description of this session from the event guide says that “When you combine developer attitudes with government legislation and online media, the results are uniquely Canadian perspectives on the state of digital accessibility.”  I wonder if this means that all their perspectives are extremely polite and amiable?  We shall see…oh wait, I just spied a picture of Justin Bieber in the slide deck.

Presenter:

 

Two perspectives:

  1. What’s happening in industry and broadcasting/publishing in general
  2. Legislative perspective

 

Legislative perspective in 2007/2008

We didn’t really have much.  At federal level, we had committed to WCAG1.0 until WCAG2.0 was adopted later.   The private sector’s timeline was a bit different, which Billy will talk about later.  Ontario largely led the charge, followed by Quebec in 2011.  Until recently, there wasn’t much happening that you’d hear about in the international media.

Patrick talked about the results of his 5 year media review (2009 – 2014) of about 15 major sites in Canada (including CTV, CBC, The Weather Network, Canada.com, Toronto Star, etc.).  He reviewed top sites for accessibility on forms, multimedia, tables, structure, clear, focus.  2009 only 7.8% of all tests were satisfactory.

 

Billy talked about the development side of the equation.  In 2009, accessibility was mentioned, but rarely practiced.  WCAG2.0 was only recently published as a recommendation.  Developers were busy building carousels, modals, tabs, and other features that would grow to haunt them later.  The situation was bleak!

 

Denis then picked up and talked about his experience getting up-to-speed on legislation in 2009.  He contacted all of the provincial governments to find out what they were doing.  He asked the following 6 questions:

  1. Are there any specific web accessibility standards set for your country/province?  (Mostly no)
  2. Are these standards abased on existing W3C accessibility guidelines?  (Yes)
  3. What conformance level if any is expected for these standards?  (mostly level AA)
  4. Are there any implementation deadlines planned for compliance?  (Mostly no)
  5. Do these standards apply only to government web sites?  (Mostly government web sites)
  6. Are the standards enforced as mandatory policies or just as recommendations? (Mostly recommendations)

The responses allowed Denis to build a ranked grid of sites, with ratios of errors to pages.  This was interesting.  He also transcribed these ratios into a heat map of the actual map of Canada.  This was really interesting.

 

Patrick then took the mic to talk about the 2014 web sites assessment.  This time, 27% of all tests were satisfactory, based on the testing criteria.  The upshot is that ALL CRITERIA IMPROVED.  This is a big deal, but still a long way to go.  Patrick fielded a number of questions about the tests.  Denis answered a question regarding web accessibility for organizations that have a web presence in Ontario (those with a presence over 50 employees).

 

Billy then talked a little bit about today’s community.  Informal poll shows that accessibility is still overlooked by some agencies.  It’s not mentioned as a service, and is rarely mentioned in past work.  However, accessibility camp attendance is WAY up.  AODA is probably driving a lot of involvement.  Developer attitudes are very positive.  Meetup groups are gaining in popularity, and developers outside of the accessibility community are speaking about it.  Our camps and Meetups fill up immediately…and we have waiting lists!

 

Denis asked session attendees if they would share some ideas about what they think the future holds for web accessibility.  Elle Waters said that their company is seeing fewer requests from clients requesting assistance with compliance-related issues.   George talked about his concern that accessibility is still aimed at organizations and governments, not individuals.  A comment was made about the law in Canada not having too much wiggle room and “not enough teeth.”  Some municipalities are actually actively avoiding compliance with the law or putting it off.  In some cases, Canada is looking at litigation in the United States as actually being a good thing that can spur action.  Denis wrapped up by saying that our aging populations will likely be a driving force in adoption of and demand for accessibility.  By 2061, over 1/3 of the population will need accessibility.

 

Online Media Future

  • Room for improvement
  • Change is happening
  • awareness still needed
  • legislation is making an impact
  • improving development culture

 

 

 

Categories
Accessibility Technology

Building An Accessible California Online Voter Registration Web Application

This is my second session from the second day at the CSUN conference.  This session covers “”

Presenter:

  • Jennifer Bretschneider, Office of the CA Secretary of State
  • Chris Maio, Office of the CA Secretary of State
  • Cheryl Pruitt, CSU
  • Mark Turner, CSU
  • Susan Cullen, CSUN
  • Aminie Elsberry, Office of the Secretary of State
  • Lucia Greco

 

Cheryl described some of the collaborations between a number of different California government agencies.  They leverage

 

Lucia Greco talked about testing of the application by testers remotely across the state.  She then demonstrated the voter registration application itself, using a laptop with a screen reader.  The form follows best practices with respect to form controls.

 

A user in the audience commented that his group tried testing but found the form not completely satisfactory.  Lucy indicated that they found JAWS needs to be switched to beginner verbosity mode for it to work properly.  Jenny then addressed the comment, indicating that this was the very first project where they’ve had the CSU and community testing at the same time.  The communication itself was admittedly clunky and awkward at times.

Jenny then discussed converting the paper-based voter registration process into an automated online process.  The first version of the app was built with a federal grant and had a nine-month window to get the app done.  Over one million people applied using this app.  The second version of the app (which was demonstrated by Lucy) was built in consultation with the CSU.  Chris then talked a little bit about the cross-organizational team that built the app.

COVR1 to COVR2

  • No more CAPTCHA
  • Eliminated a screen refresh issue
  • 19 pages reduced to jest 2 pages plus review
  • Added proper structure (headings, legends, labels)
  • Added ARIA and HTML5 tags
  • Grouped questions logically, rather than adhering to the printed form order
  • Added more help content (web site help and accessibility pages, 800 number in the footer of every page)
  • Made it easier to complete the form accurately (added more drop-downs, radio buttons and checkboxes).

 

Launch Dates

  • Voter info guide: Launching April 6
  • Election results:  June 2
  • Redesigned SOS web site – summer launch

 

Sue Cullen then talked about how they applied principles of Universal Design to Web Application Development.  UDC Evaluation Categories include the following:

  • Section 508 / WCAG2.0 / Common Sense
  • Alternative Descriptions, Multimedia, Structure, Comprehensive Visual Display, User Interface, Navigation

 

Mark Turner then talked about testing the PDF accessibility.  Defined accessibility standards as WCAG2.0.  They met with developers prior to document development.

Project Scope:  Two dynamically-generated documents provided to end-users

  • 1-page receipt (if DMV lookup is successful)
  • 3-page receipt plus registration (if DMV lookup is unsuccessful)

 

Evaluation Methods/Tools

  • Automated check using Adobe Acrobat XI, PDF Accessibility Checker
  • Manual review of content tags, and metadata
  • Assistive Technology (i.e. JAWS, Read Out Loud)
  • Summary reports to developers, including findings and recommendations

 

Lessons Learned

  • You must use multiple testing methods.
  • AT clarified what end-user experience would be
  • PDF generation libraries can’t automate accessible authoring
  • PDF remediation steps must consider the programming tool

 

Question:  how do you deal with forms that are “hemmed in” by legislation?  Some things you can change, but some you can’t.  We were able to do fairly simple things like change the order of a few things.  However, some language we simply cannot change.

Question:  can you increase the font size by 200% and have it still usable?  Yes.

Categories
Accessibility Technology

iOS vs. Android, a Web and Native Application Accessibility Comparison

This is my first session from the second day at the CSUN conference.  This session covers “a comparison of accessibility and WAI-ARIA support in Android and iOS.  Which ARIA features work in one, both, or neither of these mobile platforms.”  I met Paul at CSUN in 2013, and he’s both an enthusiastic and opinionated developer.  This makes his Twitter feed fun to watch at times 😉

Presenter:

  • Paul Adam, Accessibility Evangelist at Deque (@pauljadam)

 

RESOURCES

 

Google has done a great job improving Android’s accessibility API, but is still a few years behind Apple.  Paul showed Apple’s UIKitFramework and some of the properties available when using XCode, including:

  • accessibilityViewIsModal()
  • accessibilityPerformMagicTap()
  • UIAccessibilityPostNotification()

Sending focus to items is much easier in native apps versus mobile web apps (web is not a nice controlled environment and still has a way to go).

Adding descriptions to images in Android:  androidcontentDescription

XCode allows you to add content descriptions via GUI or programatically.

 

WAI-ARIA Live Demos

There’s a WAI-ARIA attribute support matrix available from Paul’s presentation (see resources link above).  The matrix is not exhaustive, but let’s give Paul a break, eh?

ARIA is generally well-supported in current browsers.

Paul then opened up a web page made by Andrew Kirkpatrick that had some pictures with ARIA tags for people to test how different browsers handle the tags.

With Live Regions you can make the screen reader read entries on-the-fly.  However, you need to have a container painted on the page to receive updatable content.

 

Paul then demonstrated a couple simple forms with VoiceOver showing how aria-describedby, aria-required, aria-invalid and jQuery.focus().  Paul has an iOS WAI-ARIA “fail list” on his web site which is worth checking out:  http://www.pauljadam.com/demos/aria-expanded.html

 

Apple does not support HTML5 form validation, but Google does.   Using HTML5 form types are recognized, so context-appropriate keyboards are presented, i.e. numeric keypads in telephone fields, datepickers in date fields, etc.

All mobile browser default placeholders / control outlines fail contrast tests.

 

Paul then gave a demonstration of how captions work on both Android and iOS.  Interesting fact: in iOS, you can’t make an HTML5 button say whatever you want.

 

As a user, you probably want to use iOS.  As a developer, you probably want to play with Google.  I captured a few of the platform pros/cons Paul listed:

  • A big con for iOS developers:  Apple doesn’t do a very good job of documenting fixes to VoiceOver.
  • A con for Android users:  zoom level isn’t maintained between apps.
  • Facebook and Twitter are much more accessible on iOS

 

Q & A

Question:  what are the user stats for each platform…which gets used more?  Answer: iOS is far and away the most used, according to WebAIM’s screen reader survey.

Categories
Accessibility Technology

A Pattern Library as a Foundational Sketch for Web Accessibility Efforts

This is my seventh session from the first day at the CSUN conference.  This session covers LinkedIn’s DaVinci UI Pattern library, which “…demonstrates accessible web patterns that designers and developers can combine into a work of art.”  I’m a big believer in the idea that having published standards can help guide an organization to be consistent with how they do things across channels.  Very much looking forward to this session.

Presenters:

 

RESOURCES

 

SLIDE ONE

Some details about LinkedIn and their mission statement…

 

SLIDE TWO

Accessibility Task Force

  • 12 cross-functional team members
  • Design, web dev, iOS engineering
  • Weekly meetings
  • Review designs and code in progress
  • Working a prioritized backlog of enhancements in existing products

Scrum-style process.  We’re building out a group of full-time professionals to help us with accessibility.

 

SLIDE THREE

A set of pictures that highlight LinkedIn’s mission to help everyone

 

SLIDE FOUR

Getting leverage

  • Company has 1000+ developers
  • Size of dev team has tripled in 2 years
  • Leverage methods

A driving question:  how can one person (or a small team) effectively communicate with such a large development team?

 

SLIDE FIVE

The DaVinci Pattern Library (brings together art & science)

  • Online library of UX patterns for web and mobile
  • Design variants documents
  • Dev implementation documented
  • Accessibility notes (when appropriate)
  • A common language

LinkedIn is considering open sourcing this…”dust” framework and “archetype” are already available.

 

SLIDE SIX

Library overview

Have several sections to their library; there are separate sections for mobile and desktop.  Each section has samples with “exemplifiers” that highlight what it actually looks like in action.

“Patternable things” can be contributed to the library after at least two development teams have done something that looks like – and they have been identified as – a pattern.

 

Drew took over and reviewed the iconography the site uses.  They’re switching to use webfonts now instead of sprites because they scale better and are much smaller in size.  They also have an accessibility that explains how the icons should be coded so it is properly represented by screen readers appropriately (and not read out loud as unicode).  Drew then spoke a bit about dialogs and how they should look (modeless and modal).  Dialogs are given focus, are dismissed by the escape key, and place focus back on the previous element after dialog is dismissed.

 

Sarah then talked about the slider control, an emerging pattern at LinkedIn.  It can be used with numeric values ranges and also discrete values i.e. for privacy (more open, default, private).  Arrow keys move it one increment, while page up/down moves 10, home/end keys move to lowest/highest values respectively.  Both HTML samples and Dust partials are available for implementation to internal developers.

 

Drew then described how forms are implemented.  Stacked forms are preferred to “sided forms” because some languages are more verbose than others.  They’re replacing JavaScript select boxes, which is saving load times.

 

SLIDE SEVEN

Sarah talked a bit about Future Patterns

  • User cards
  • Drop down/overlay controls with full aria
  • Global and page-specific keyboard shortcuts
  • iOS7-style toggle to represent a checkbox

 

Q & A

Question:  How old is DaVinci?  Answer:  about a year and a half.

Question:  This is a lot of overhead, is it worth it?  Yes, developers are expected to deliver value horizontally and contribute to this.

There were a number of really great questions about practical implementation details as well, sorry but I didn’t catch ’em all 🙁

Categories
Accessibility Technology

Web Accessibility Myths for the Mobile Generation

This is my sixth session from the first day at the CSUN conference.  This session covers “…the many things accessibility advocates believe are outdated.  Updating his popular Accessibility Myths blogs, Jonathan Hassell uncovers the worst offenders and replaces them with well-researched facts.”  This description comes from the conference event guide.  Now, I’ve never met Jonathan Hassell, but I’ve read some of his blog posts in the past.  I sure hope his session meets the high bar his session description sets.  I want the names of the skeletons in the closet!!

Presenter:

  • Jonathan Hassell, Hassell Inclusion, ltd. (@jonhassell)

 

Some bona fides…

  • 13+ years experience in accessibility and inclusion
  • Wrote UK standards BS8878 & chair of its drafting committee
  • Former head of usability and accessibility, BBC Future Media
  • A number of awards
  • A bit of book-flogging 😉

I like to challenge the orthodox views; some may surprise you.  However, it’s all based on data and research.

 

Myth 1:  What disabled and elderly people need is accessibility

  • They actually want a site to be usable, just like everyone else does
  • You have to be able to deliver a good experience
  • “Accessibility is just the engine…you still need the rest of the car to work to get you there”

 

Myth 2:  All you need is WCAG 2.0

  • It’s a little old (2009), and sites you use on a daily basis have probably changed since then.
  • WCAG is useful for web sites, developers, designers, requirements managers.
  • Other WAI documents are useful…but the reality is that very few folks code web sites from scratch; most sites are mash-ups.
  • It’s more about how you choose to integrate the variety of technologies that are out there.
  • Things are less about technical accessibility and more about the process of creating and procuring technology.

 

Myth 3:  The Best business case for accessibility is the law

  • If an organization’s web product is not accessible to a disabled person, that person might have grounds fro making a claim against the organization under different countries’ laws & regulations (ADA, CVAA, Equality Act, AODA, DDA, etc.)
  • However, outside the USA there’s very little case law
  • The last thing you probably want to do is do the bare minimum as “insurance” against being sued.
  • You’re much better off using accessibility as an ethical business case.

 

Myth 4:  Accessibility is cheap / expensive (depending on who you ask)

  • It really depends on how what it is you’re trying to make accessible
  • WCAG is not very helpful at determining cost of remediation, i.e. -text=cheap, time-based media=expensive

 

Myth 5:  We won’t get enough return on investment

  • Definition of disability is really important.  Numbers are probably rather low, because not everyone self-identifies.
  • One way to think about it is to “Design for your future self”
  • Different checkpoints have wildly different potential reach benefits
  • We should compare our “pressure group” to SEO industry…we need to start counting, like everyone else does

 

Myth 6:  If you build it (to be accessible), they will come

  • Not so!  How do you market to disabled audiences?
  • You have to tell people about what you’ve done, and there aren’t many specific channels for doing this.

 

Myth 7:  Accessibility and Inclusive design are anti-creative

  • Innovative challenges offer creative solutions
  • Mainstream inclusion vs beyond inclusion
  • OXO good grips as a success example
  • Audio game mainstreaming as a success example
  • Apple CarPlay as a success example

 

Myth 8:  Accessibility and Inclusive Design Help Everyone

  • It does have its problems…you can’t please every audience
  • Sometimes you just can’t win
  • This is why personalization is necessary; use themes where possible or use a tool that enables is

 

Myth 9:  Disable people use assistive technologies

  • Only about 6-8% of people use assistive technologies
  • Microsoft/Forrester did a research study in 2003 that showed that 57% of USA computer users were likely or very likely to benefit from Accessible Technology
  • Many platforms don’t include accessibility controls anymore, while there’s simultaneously fragmentation among AT solutions

 

Myth 10:  Accessibility is just about blind people

  • Nope.  They’re only 2%

 

Myth 11:  Text is More accessible than other media

  • People prefer pictures

 

Myth 12:  The most important thing is alt text

  • How about using better images?

 

Myth 13:  Most important people in accessibility are developers

  • No, it’s everybody

 

Myth 14:  Desktop version of your site is accessible, you don’t need to worry about the mobile version

  • Better to think about this exactly opposite

 

Myth 15:  Web sites need to be accessible from the start

  • Get an MVP first and iterate

 

Myth 16:  the standard is just for huge companies

  • Nope.  It’s for everyone.  A great product benefits everyone.
  • It’s an effective set of guidelines for creating effective web sites.