Category: Technology

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.
Categories
Accessibility Technology

All About Google Chrome

This is my fifth session from the first day at the CSUN conference.  This session covers “…the built-in accessibility features of Chrome, Chrome OS and Chromebooks.”  Description comes from the conference event guide.  I attended Google’s pre-conference seminar in 2013, and it was very informative (my 10-part blog post can be accessed here).  I hope they pack in the juicy details this year too 🙂

Presenters:

  • Dominic Mazzoni, Software Engineer on the Google Team (@)
  • Peter Lundblad, Engineer on the Google Chrome Team (@)
  • David Tseng, Software Engineer Google Chrome Team (@)

 

David Tseng showed off a remote control that comes with ChromeVox built-in.  It’s meant for video conferencing.  David used the tool to join a Google Hangout (a kind of vido call).  It worked well in the demonstration, at least from the perspective of selecting and joining an existing Hangout.

 

Dominic Mazzoni talked briefly about the importance of the web as the world’s largest open platform.  The Chrome browser was originally introduced with the following three principles/priorities in mind:

  • Speed:  re-introduced competition into the browser market
  • Simplicity:  create a browser that doesn’t distract from the content you’re looking at.  Also, updates happen automatically.
  •  Security:  updates resolve holes asap

Dominic jumped into ChromeOS and showed some of the accessibility features available, including on-screen keyboard, screen magnifier, large mouse cursor, high contrast mode, sticky keys, tap-dragging, and ChromeVox itself.

 

Peter Lundblad demonstrated ChromeVox, a screen reader made especially for ChromeOS.  Support for voices in multiple languages has been recently added; Peter demonstrated this with both German and British female voices.  Refreshable braille device support has also been added to ChromeOS.  This particular demonstration was interesting to me because I’ve never actually seen one of these devices in action.  There is a “growl-like” on-screen display of the braille output so sighted users can see what the braille device itself is showing.  Peter added a bookmark using the braille device.

 

Dominic then took over and talked about synchronized bookmarks (and other settings) that “follow the user” to whatever device they may be using.  He demonstrated this using an Android phone.  The phone he showed the audience successfully showed the bookmark that was set by Peter on the Chromebook a few minutes before.  Dominic then activated the local search control (a circular control with links to phone functions) by swiping up and to the right to activate the link.

Dominic then demonstrated the ChromeCast, which lets you “cast” content from any Chrome browser to a display the Chromecast is plugged into.  Laura Palmero shared her personal experience using the ChromeCast.  Laura is a person with a vision disability that makes it difficult for her to view things in the center of her field of view, so she relies on high-contrast displays that are close to her (like her phone).  This has made it much easier for her to interact with her large screen television at home…she now controls it using her phone, which she uses all the time.

 

Question:  what about the accessibility of Google Docs?  There is a Google Docs session tomorrow (Thursday) that goes into great detail about Google Docs.

Question:  what is the strategy with ChromeBook?  It seems like just an interesting toy.  Answer:  it’s not a general-purpose computing device that’s meant to replace all computers.  It’s a device that’s made to work with the web,

Question:  what tools are you providing so developers can have access to things like view source, that sort of thing?  Answer:  we know we have some work to do with this, but there are workarounds.  Please speak with us after the session.

Question:  how well does it support ARIA?  Answer:  we make extensive use of ARIA in our web apps, and we rely on open standards and participate in working groups.

Categories
Accessibility Technology

Scaling Web Accessibility at Facebook

This is my fourth session from the first day at the CSUN conference.  This session “…covers Facebook’s work over the past year to scale web/mobile accessibility across the company’s large engineering department.”  Description comes from the conference event guide.

Presenters:

  • Jeffrey Wieland
  • Ramya Sethuraman
  • George Zamfir (@good_wally)

 

RESOURCES

 

BACKGROUND:  how to scale accessibility in a large engineering environment.

  • Complexity:  Each platform has different considerations
  • Awareness:  products need to know what do for accessibility
  • Speed:  need to integrate accessibility into the process

 

JEFFREY’S SEGMENT

Accessibility team came into existence by recognizing that users were using AT to mediate their relationship with the product.  Jeffrey appealed to user interface engineering (UIE), which is the front-end team that builds all the core components of the product.  These components are similar to the design pattern library work that LinkedIn is doing.

Unfortunately, most Computer Science graduates do not have much exposure to accessibility.  So, accessibility has been integrated into the core training regimen at Facebook.  If it’s a part of the core training, then it sends a message to the developers that it’s important.

Testing matters, so we’ve invested in something called an “accessibility nub” which is essentially a flyout menu (built in-house) that allows developers to toggle looking for best practices.

Centralizing documentation and best practices has helped engineering review things “in-context.”  Contextual links to this resource have been embedded wherever needed.

These steps have give us the ability to “have more hands on deck” with respect to accessibility.  This has grow the number of developers working on accessibility fixes to over 80(!)

A number of ambassadors have been enlisted to help evangelize accessibility internally.  We also have channels by which we communicate with our users (see resources section above)

 

RAMYA’S SEGMENT

Ramya began her segment by describing the alt text issue she had posting a picture of her one year-old daughter trying yogurt for the first time (very cute!).

Caption generator:  takes bits of metadata about uploaded photos and auto-generates a caption for the user.  Ramya demonstrated how this sounds with VoiceOver, both before and after using the caption generator.  Addition of  metadata elements like location photo was taken was very effective!

Semantic Structure has been added via headings and landmarks.

The core components library contains controls like buttons, links, images, etc.  Accessibility is built directly into these components.  Dialogs now have keyboard enhancements, with appropriate labeling.  Focus cycles through dialogs.

Keyboard Shortcuts:

  • j/k keys are used for moving focus forward and backward, respectively.
  • “c” key is used to comment on a post
  • “s” key is used to share the post,
  • “o” key is used to open attachments like photos
  • “q” key to chat.

High contrast mode is also available now.

A lot of effort was put into making the desktop view accessible.

 

GEORGE’S SEGMENT

Quality Assurance:  all is done with scale in mind.  It all started with a spread sheet, and testing was done in an ad-hoc fashion by a very small accessibility team.  In order to scale it, it had to be spread to the entire team!

We now run standardized regression tests on a regular basis for each platform.  We also do user testing with people who have disabilities.

QA (test run) > ProdOps (triage & assignment) > Eng (improvements)

Where does the A11Y team fit into the above?  It fits in wherever it makes sense.  Across products & platforms, and runs on auto-pilot.

“If you build the product, accessibility is YOUR responsibility.” It’s just another form of code quality.

 

JEFFREY’S SEGMENT

Mainstreaming accessibility is something that we want to pursue at all levels.  One of their front-end engineers was working on the web messenger product, and when asked if he’d tested with a screen reader, his response was “what’s a screen reader?”  This is not his fault, because he was not exposed to accessibility during his education.  So, Facebook is now partnering with PayPal, Stanford engineering to get students to think about accessibility.  This will help to build awareness.

 

Q & A SEGMENT

Question:  how much of the data associated with the photo example presented earlier is auto-generated versus user-supplied?  Answer:  it has be user-entered content.

Question:  how are you testing for high-contrast mode?  Answer:  well, it’s complicated…(I didn’t catch all of the answer).

Question:  are the testing links you talked about generalizable for use by public testers?  Answer:  not really, but we’re working on it.

Question:  how do you track focus when using keyboard shortcuts?  Answer:  we return the currently active element.

Question:  have you been able to document whether or how the accessibility features have been implemented?  This is a big challenge, quantifying the impact your work has made.  We’re doing a lot around measurement, which helps improve where we focus our efforts.  We do read all of the feedback we receive, both positive and negative…please be candid with us!

Question:  where does the role of the engineer start and end?  Where does design fit in…how do you get accessibility baked in?  Answer:  we’re still defining how this works Facebook.  Some things engineers should absolutely be involved with, notably focus and readback.  Things get trickier when building more dynamic and collaborative tools.  George indicated that their designers were ready to roll straight into implementation and pretty much ate up everything he gave them.

Question:  do you need to activate keyboard shortcuts somewhere in the user preferences?  Answer:  no!

Comment:  I wanted to mention that I submitted a JavaScript-related accessibility bug recently and got a response THE SAME DAY.   Very great high-touch service (this got some applause).