CSUN 2013 notes

The 28th Annual International Technology and Persons with Disabilities Conference, better know as CSUN 2013, took place February 25 to March 2, 2013. I attended the general sessions portion and provide here the notes I took from some of the sessions I attended.

WCAG Guidelines – What about the Users?

Speakers

  • Birkir R. Gunnarsson
  • Hinni Hreinsson

Screen reader usage and trainer

  • Many users run multiple screen readers
  • 21% of users had formal training with screen readers
  • 80% use their screen reader webpage summary feature

Familiarity with landmarks, headings, and table navigation

  • 1/3 are familiar with and use landmarks
  • 60% are familiar with and use headings
  • 61% are familiar with and use table navigation hot keys to browse tables

Web page exploration strategies

  • 80% of users use tab and arrow keys to explore pages
  • 8% of users use TAB and arrow keys exclusively
  • Large part of the user base rely heavily on TAB and arrow keys to navigate a webpage
  • Most also have other means of navigating

Suggestions for improvements

  • Web developers: use markup clearly and efficiently

Be the Fireman and not the Cop

Speaker

  • John Foliot

Current problems

  • Lack of accessibility planning / pre-planning
  • Stakeholders already on the defensive
  • Tight deadlines
  • No budget allotted
  • Content being developped without web acccessibility in mind

Resistance to change

  • Confrontation
  • Rejection
  • Avoidance
  • Insincerity

Finding the champions

  • It takes a cultural shift
  • Key is good communication and communicators

The law of the few

“The Tipping Point” by Malcolm Gladwell

  • Find:
    • ‘Connectors’ – know everyone, have done everything within the company
    • ‘Mavens’ – tech gurus, hardcore geeks
    • ‘Salesman’ – promoters, persuaders

Communication skills

  • Be likable, stay positive – all the time!
  • Connect – find mutual points of interest
  • Solve problems and build trust – teamwork starts with you
  • Create positive experiences – make learning fun
  • Identify and recruit the few

Establishing the systems to get you there

Tackle technical challenges

  • Standardise CMS use so you can solve problems in one place
  • Track bugs
  • Use frameworks to get accessibility built in
  • Create custom tools for internal use
  • Standardise evaluation tools

Tackle cultural challenges

  • Provide detailed expectations of outcomes, not dictate the solution – encourages creativity
  • Set realistic goals and expectations
  • Lay out the efforts as challenges not consequences
  • Don’t worry about the pursuit of quality – don’t let perfect be the enemy of good
  • Set timelines and milestones
  • Foster empathy and understanding
  • Brownbag events – invite actual users with disabilities

Addressing financial challenges

  • Be honest about how much it will cost
  • Scaled question – the longer you delay the more it costs

Transition towards a team based approach

http://www.w3.org/community/wai-engage/wiki/Accessibility_Responsibility_Breakdown

  • Identify the responsible people
  • Identify bottlenecks in each group independently

Establish training and internal resources

  • Motivation – internal awards, recognition, etc.
  • Document knowledge – wiki etc.
  • Aim for consitency of implementation

Legislation, policy, and best practices

  • Accessibility is a governance issue, and a shared responsibility
  • Appeal to pride instead of fear
  • Create a policy: work with existing standards, avoid re-inventing the wheel
  • Lose legal threat as a last resource

Measuring success

  • Avoid checklist mentality
  • Avoid apprearances of making concessions and sacrifices
  • Avoid overly long and complex accessibility reports
  • Make accessibility more than a QA process
  • Work with milestonesL test early and often
  • Be specific with what you ask for but generous with what you accept
  • Celebrate successes, both great and small

Agile and Accessibility: Theory and Reality

Speaker

  • Karl Groves

Waterfall approach of accessibility

  • Accessibility is a thing that intrudes at the end of every phase
  • If accessibility isn’t specified as part of a phase then accessibility isn’t going to get handled for that phase
  • Accessibility isn’t part of the discussion, it is an approval step

How do agile and accessibility work together?

  • Definition of Done
  • Inherently user focussed
  • Inherently quality focussed
  • Inherently collaborative

Tools and techniques

  • Test-driven development
  • Daily stand-ups
  • Definition of Done

Case Study: Fortune 100 Healthcare Company

Some Design Up Front (SDUF)

  • Spec work on what pages should look like
  • 95 initial reenderings (snippets of UI elements)
  • 9 page types
  • 10 sub-layouts

Traditional scrum

  • Accessibility team members assigned to several scrum teams
  • Before each story was considered complete it had to be cleared by accessibility team member

Deviations from the process

  • Underestimated scope
  • Underestimated resources
  • Untrained resources
  • Executive staff unwilling to adjust to meet evolving needs
  • Agile-fall!

Lessons learned

  • No project management system will assure success without knowledge and skills required to be effective
  • Accessibility can be integrated into any process
  • You must follow the process to realise the benefits
  • Time spent up front building accessible componenets and patterns is good accessibility ROI (still expect to refactor later)

Accessibility in Firefox for Android

Speakers

  • Marco Zehe
  • Eitan Isaacson

Android versions

  • Android upgrade is slow
  • Most common version is Gingerbread (2.3)
  • Latest version, Jelly Bean (4.1 and 4.2) is 3rd most common

Android accessibility

  • Jelly Bean has very good support
  • Gingerbread and earlier have very basic support

Firefix for Android

  • Each version has improved support for native navigation options
    • D-pad navigation (2.3+)
    • Explore By touch (4.0+)
    • Gesture navigation (4.2)
  • Additional navigation options built in to Firefox
    • Keyboard quick navigation (2.3+)
    • Gesture quick navigation (2.3+)
  • Firefox adds support for native navigation options to earlier versions of Android
    • Explore by touch backported to 2.3
    • Gesture navigation backported to 2.3

Infographics – Making Images Speak

Speaker

  • Ted Drake

Longdesc

  • Poor support
  • Hidden content for most users
  • Allows for good structure

WAI-ARIA

  • aria-labelledby or aria-describedby
  • Removes structure, treats content as a string

aria-describedby

  • Announces element as image, reads alt text
  • Can still use content hidden with display: none;
  • Long pause before content is read, easy to miss

aria-labelledby

  • Does not label element as a graphic up front, replaces content with transcript
  • Announces element as a graphic at the end of the transcript

Include transcript

  • Allows for good structure
  • Repeats content in the infographic
  • Can be visually hidden with CSS clipping

Toggle transcript

  • Provide a structured transcript
  • Hide content by defauly
  • Add control to show the content

Transcript link

  • Add visible link to transcript

Implementing Accessibility Testing At The Enterprise Level

Speakers

  • John Foliot
  • Mitchell Evan

Testing matrix

  • Prioritise Assitive Technology / Browser combinations based on likely use and instance of problems

Test plan for each feature or page:

  • How to test
  • Expected results
  • Actual results
  • Notes

Successes

  • Use a bug database, not monolithic reports
  • Browser / AT matrix

Template for future projects

  • Kickoff: confirm the plan, meet & greet
  • Ground rules for visual design
  • Collaborate with UX design
  • Visual accessibility analysis
  • Collaborate with developers
  • Test

Mozilla Firefox OS – Mobile Open Web Platform

Speakers

  • Marco Zehe
  • Eitan Isaacson

Operating system

  • Written entirely in HTML, CSS, JS, including apps and even the web browser
  • Open source
  • Linux Kernal
  • No SDK required for development

Goals

  • Get the next billion people on to the web
  • Initial launch in Central and South American countries
  • Hardware somewhere between feature and smart phone specs for affordibility

Accessibility in Firefox OS

  • Bad news: first version won’t have a screen reader
  • A screen reader is coming soon…
  • It will share the same core accessibility engine as desktop and Android versions of Firefox

Plain Language: Usable Content for Everyone

Speaker

  • Angela Hooker

Common content problems

  • Language that needs explanation (Shakespeare)
  • Unusual structure of language (Yoda)
  • Sometimes institutions (such as government) dictate the content
  • Overly wordy content
  • Jargon that hides meaning
  • Slang or regional terms
  • “Pedantic content” – big showy words where simple words will do
  • Forgetting the audience

Plain language is…

  • writing content that people can easily understand the first time they read or hear it
  • usable and meets users needs so they can act on it
  • not forcing your users to read content several times to understand it

How can plain language help?

  • Your users will be loyal
  • Will widen your site’s appeal, audience, and influence

WCAG 2.0 principles of accessibility

  • Plaing language supports POUR
  • Plain language is ‘Understandable’ in ‘POUR’
  • Plain language makes your content accessible for all

Plain language is not…

  • dumbed down content, it’s meeting the needs of your audience

Don’t forget…

  • People with low literacy skillls
  • Pleaople with low language proficiency
  • People with cognitive impairments
  • People with dyslexia
  • People who are Deaf or hard-of-hearing
  • People who are aging

What you can do

  • Write for your specific audience
  • Write for the average reader
  • Dont’ be clever, make it simple
  • Assume audience is intelligent but don’t assume they’re familar with your topic
  • Inverted pyramid method: put the most important information at the top and the background information below
  • Be concise – cut out excess / filler words
  • Use minimal text and short sentences
  • In print people write to tell a story, but online we should write about topics so users can complete their tasks

Mechanics

  • Write in active voice, avoid passive voice
  • Use simple verb tense and base verbs (present tense)
  • Avoid ‘hidden verbs’ such as ‘provide assistance for users’ instead of ‘assist users’
  • Use complete sentences
  • Use words and terms that your users are familiar with
  • Provide direct insturctions
  • Talk with your users: use personal pronouns
  • Avoid jargon, or explain it when necessary
  • Use ‘must’ instead of ‘shall’ in requirements

Quality

  • Test with users
  • Conduct A/B testing

Summary

  • Always consider your users’ needs first
  • Your users want to complete a task
  • Talk directly to users
  • Use everyday terms
  • Don’t follow trendy content practices
  • Each medium (mobile, dekstop, app, video, podcast) may require tailored content
  • Read your content aloud
  • Test your content
  • All of these help you incorporate accessibility throughout your project lifecyle

One thought on “CSUN 2013 notes”

  1. Pingback: The Great Big List from the 2013 CSUN International Technology & Persons with Disabilities Conference | Curb Cut

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.