ATIA Chicago 2009

I attended and spoke at the Assistive Technology Industry Association (ATIA Chicago) conference last month.  The conference was focused on educating attendees about assistive technologies and their uses in the world today.  Another particular focus of the conference was creating information that remains usable and accessible by users with assistive technologies.  I attended several sessions and spent a good deal of time discussing on the exhibition floor.  Here are some of the highlights.

Presentations covered in this post:

• Web Accessibility Standards and Guidelines Update 2009
• WAI-ARIA Introduction: Making Advanced Websites and Web Applications Accessible
• Managing the Learning Curve Through the Eyes of a Parent
• Developing Prompts Using Microsoft® PowerPoint to Teach Emergent Literacy
• Creating Accessible Text and Digital Reading on iPods and Zunes
• Web Accessibility Testing (on a Shoestring)
• Bigger and Better: Accessible Music-Reading Solution for Low Vision Musicians
• Create Accessible Websites: What to do, what to ask for

"Web Accessibility Standards and Guidelines Update 2009" and "WAI-ARIA Introduction: Making Advanced Websites and Web Applications Accessible" by Shawn Henry, W3C

Abstracts:

 This presentation provides the latest on new international Web accessibility standards from the W3C Web Accessibility Initiative (WAI), and the U.S. TEITAC Committee report for updating Section 508 and Section 255 standards. WAI's Web Content Accessibility Guidelines (WCAG) 2.0 published in December 2008 defines how to make websites accessible, including web applications developed with Ajax. In 2009, WAI accessibility guidelines/standards are being updated for browsers and other user agents, as well as for authoring tools including content management systems (CMS), blog software, social networking sites, and more. This session also covers the overlap between designing for people with disabilities and designing for older users with age-related impairments. We'll review the findings and current work of the WAI-AGE project (Web Accessibility Initiative: Ageing Education and Harmonisation). You'll also get examples of the overlap between making a website accessible for a mobile device and for people with disabilities. The presentation gives you background and support for promoting web accessibility in a variety of situations, from individual websites to government requirements. You'll get a clear overview of how the different standards relate, a summary of the new requirements, and practical guidance on finding the information you need.

This presentation introduces WAI-ARIA for Accessible Rich Internet Applications. WAI-ARIA defines a way to make websites and web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. With WAI-ARIA, developers can make advanced web applications accessible and usable to people with disabilities. Currently certain functionality used in web applications is not available to some users with disabilities, especially people who rely on screen readers and people who cannot use a mouse. WAI-ARIA addresses these accessibility challenges, for example, by defining new ways for functionality to be provided to assistive technology. More specifically, WAI-ARIA provides a framework for identifying user interaction features, how they relate to each other, and their current state. For example, with WAI-ARIA, developers can identify menus, navigation, primary content, and other regions of pages, and thus enable keyboard users to easily move among regions, rather than having to press Tab many times. This session describes the problems that WAI-ARIA addresses, and introduces how WAI-ARIA solves them. We’ll also clearly demonstrate the more simple aspects of WAI-ARIA that apply even to basic websites.

My notes:

• Web accessibility evaluation is not necessarily subjective in all aspects, but still requires a human.  For example, a machine can determine if an image has alt text, but only a human can tell if the image's alt text is meaningful and appropriate.
• Don't waste time in the grey area, for example what's a decent heading, a decent alt description, things like that.  Don't get discouraged and don't bum out developers because you're nitpicking about wording and color values.
• Make sure you're doing the easy things.  Alt text and headers are easy to implement on any site and cure a lot of problems with accessibility.
• Guidelines scare users.  Break it down into usable chunks.
• If you understand the basics of how people with disabilities use the web, it will fundamentally change the way you look at web accessibility.  Watch videos, conduct user tests, do readings (not just guidelines).

A big point in both of Shawn Henry's presentations was this: use headings.  All the time.  Seriously.  And no fair inline styling it to look like a header, you have to use the header tags.

Remember, it's this:

<h1>Very Nice Heading</h1>

...and not this:

<font size="14pt"><bold>Imposter Heading</bold></font>

WebAIM's WAVE is great at checking for headings, and the IE toolbar is good, only with the exception that you have to use IE to use it :P  And of course there's always the W3C HTML validator.

<h1>Hello, I am a properly-formatted heading and I am your friend</h1>
<h2>And I am a properly-formatted hierarchical subheading and I am also your friend</h2>
<h3>If you like those guys, you're gonna love me</h3>

• Heading navigation is really needed.  The only reason skip links still exist as a means of assistive navigation in 508 is because IE doesn't support heading navigation.  Headings weren't valuable in user agents and assistive technologies for a while, so authoring tools were less inclined to include them or make their use apparent.  Now though, the far majority of assistive technologies use headings to the user's advantage.  
• WAI ARIA is supported in the newest version of JAWS but like any great leap in technology, we have to wait until all of the average users catch up to them here.  
• When adding splash to your site via things like AJAX, Flash, etc, use the "AJAX temperature gauge" to determine its use and need: are you including it because it's hot/cool or because it's necessary?
• Depending on your situation, you may be able to use ARIA now (if you have an Intranet application).

"Managing the Learning Curve Through the Eyes of a Parent" by Janee Haniuk and Brandi-Lynn Greig.

Abstract:

This presentation discusses how to manage the learning curve necessary for both the individual who is beginning to use a speech-generating device and also their family. Through the eyes of this parent, the need for a methodological paradigm, strategies for use and integration in the home, school, and community, and materials that are easily accessible to families will be reviewed. There are many creative ways to implement language development strategies while on the learning curve with a device by using free websites, books, libraries, and hands-on activities. It is essential to consider how to build and extend language in creative and interesting ways to engage a learner and enable people to gather their own data.

My notes:

• Childrens' learning speech should be organic, interactive, and engaging.  There are many learning resources available and instructors can take advantage of these even outside the school.  talk with a child and build, what your experiences are as they happen.
• Resources for learning: 
  • http://www.storyplace.org
  • http://www.teacherplanet.com
  • http://www.bbc.co.uk/cbeebies

"Developing Prompts Using Microsoft® PowerPoint to Teach Emergent Literacy" by Craig Blum, Howard Parette, and Emily Watts

Abstract:

Direct instruction has been a widely used teaching method for over 40 years, and is often used to teach emergent literacy skills. Recent direct instruction research with at risk preschoolers has suggested the potential for using scripted, direct instruction-supported PowerPoint™ slides delivered with an LCD projection system to teach word recognition skills. An array of Microsoft® PowerPoint TM features enable education professionals to develop innovative and engaging curricula materials, though use of 'prompting' features within such materials may markedly enhance the delivery of instruction. This presentation will focus on specific PowerPoint TM features (e.g., text and color manipulation, embedding graphics and sounds, and use of transitions and animation) that are used to develop prompts in curricula materials. Examples of prompts will be shown, coupled with explanations of how they are created. Use of prompts previously reported within a research-based curriculum designed to use direct instruction and delivered using an LCD projection system will also be highlighted.

My notes:

• Powerpoint templates for young-learners lesson plans only last between 5 and 11 minutes, generally.  Very short but still effective.
• Prompt types include pictorial/written, model, time delay
• Prompts are: animations, motion-path features, etc. within Powerpoint
• Pictures/written prompts: pictures or line drawings that tell a child how to perform a behavior, for example "point to the cat".
  • Pictorial/audio stimulus prompt (word "cat", pic of cat, "meowww")
• Using Powerpoint animations, teachers can quickly and easily create interactive learning tools for children learning to read.  My own question is, can we export these as HTML, PDF, or in some other format and make them accessible? =)  The prompts are very helpful as learning tools but students with disabilities may miss out on them as they are presented.
• Costs of time delay prompts:
  • progressive time delay: gradual, and builds a dependency so that students learn faster.  They may begin to learn faster and answer a question within the time delay rather than only after the teacher has triggered the answer in the lesson plan.
• Caution: in our excitement to use animation, we can sometimes overdo it.
• A prompt is divulging what is the correct answer.  Start with shorter delays, for example ask a question and a second or two later, get a response, then the following week, ask a question, wait 5 - 10 seconds before the response.  The student will ideally become confident enough in the learning material that he or she answers before the prompt comes.
• Young children tend to like these prompts, motion paths, animations, often asking the teachers to "do it again! do it again!" thereby reinforcing the material.  Just as long as this is accessible to all, it works.  Again however, my personal question is, how should educators with access to only the Microsoft Office Suite make these clearly-inaccessible features of the lesson plans created in Powerpoint, accessible to students with disabilities? 

"Creating Accessible Text and Digital Reading on iPods and Zunes" by Daniel McNulty

This was a very entertaining and interesting presentation, but not what I was expecting.  Rather than pushing XML, hacked iPhone apps, or some specific hardware or software assistive technology, McNulty essentially presents ways to bring lesson plans onto mobile devices.  Formats covered included video, audio, synchronized media, text, images, and Powerpoint.  It's ultimately up to the developer to use these techniques to bring the media onto mobile devices in appropriate ways for helping disabled students.

Abstract:

A low estimate of 150,000,000 iPods have been sold since May 2008. Our students understand this method of delivery. It is a socially valid and relatively inexpensive way to improve the accessibility of most traditional classroom materials. Many students who have difficulty accessing traditional printed versions of tests, quizzes and other text based material in the classroom have had success accessing material digitally. This session focuses on placing tests, quizzes, worksheets and other material onto iPods/Zunes in text format, slideshow format, audio format and video format. This will be done using almost entirely free software, which will be included on a CD for participants to take back to their schools and offices. This can easily be done on both Mac and PC Computers. This is a hands-on session (PC or Mac) for teachers, paraprofessionals, therapists and administrators to learn and practice several methods for placing digital content on portable devices like iPods and Zunes. Tests, quizzes, worksheets and other text material will be placed on these devices in simple text, still image slideshow, audio and video formats using almost entirely free software.

My notes:

• iPods are good for ATs for students because they can walk down the hall, in the classroom, and transport these devices with ease.
• The most important thing with sound quality is microphone placement, not microphone quality.  Try this test: take your index and middle fingertips and place them directly in front of your lips, then make "P" and "B" sounds.  That reverberation is murder on sound recordings.  Use Audacity to edit recording for free. 
• Most MP3s, including those purchased through iTunes are exported at 128kbps, which is well-below CD quality but users cannot usually tell the difference.  Exporting at 128kbps allows for smaller file sizes without sacrificing quality to the point of obscuring data.
• Vox Machina, Orator, TypeIt ReadIt are all good synthesized text programs for the Mac.  Synthesized text programs can be used for mostly text-based lesson plans such as lectures, so that you can make your lesson accessible without having to record yourself speaking all of the words.
• Make your voice recording or synthesized text recordings, then make your lesson plans in Powerpoint and export the slides as jpegs.  Synchronize your images with your iPod.  You don't get text by doing this.  This was the suggestion in the presentation and McNulty did point out that this technique will not give the students context for the images.  They'll have to read/listen to the text and then observe the slides separately.  From my own experience, Garageband (an audio-editing program that comes free with Macs) works like a charm for creating lessons like this.  Simply create a podcast and sync the slides over the text in the album art layer.  I also suggest adding a small sound prompt to let the student know that the slides have changed when moving on to the next slide, to reinforce the lesson's advancement and to aid users with cognitive or perceptual disabilities.
• To make iPod movies, use CamStudio on the PC (like Camtasia but free).  Record your computer interactions, export them as videos, and send them to the iPod.  Don't obsess over making it a perfect recording, but you can use the video recording on your Smart Board by converting it in high quality to format such as Switch or MPEG Stream Player.
• A side note: iPod Notes does not work on the iPhone or iPod Touch.  Microsoft Word 2008 and higher has a built-in function that will convert text to audio and export it to an iPod, so that's pretty cool.

"Web Accessibility Testing (on a Shoestring)" by Nathan Zak and Mike Scott

Abstract:

Testing web sites for accessibility can be overwhelming -- Which standards should I use? What do they mean? Is this how assistive technologies really work? In this 60-minute session, we will share the secrets learned over 15 years of training web developers to create accessible systems. We will demonstrate and discuss 12 simple tests that will reveal the majority of accessibility problems without having to use complex and expensive assistive technology tools. You will learn which of the W3C guidelines and Section 508 standards each of these tests can address and how the issues they reveal can impact real uses with disabilities. We will discuss how these tests can be incorporated into the web development process for maximum savings of time and money. And, we will identify which tests must still be done using assistive technologies and the best practices -- and common pitfalls -- of assistive technology testing. If you are a web developer, accessibility tester, or just interested in how to tell if a web site is accessible, this session is for you.

My notes:

• 10-20% of Americans have or will have a disability.
• Find your standard: 508/WCAG is standard for most, but find out if your state has its own.  For example, Illinois has the Illinois Information Technology Accessibility Act.
• How do we know if a web page is accessible?  Test, test, test. (Seriously.)  Try the Functional Accessibility Evaluator (from University of Illinois)
• Testing methods: automated testing tools, code review, testing with assistive technologies.
• Testing is not just downloading the demo of JAWS and seeing if it "talks" when you bring up your website.
• Well-intentioned users with disabilities know the assistive technologies well but they don't know how to do usability testing.  A real-world example is of a disabled user who reported a system as being inaccessible for the following reason.  The user attempted to log in to the system, but a pop-up window came up and refused the user entry.  Rather than an accessibility issue, this turned out to be caused by a security setting on the user's browser.

There are many free and easy tests and techniques available through the browser.  Here you can find many (but not all) accessibility issues.  Shoestring testing will identify the biggest and easiest to solve accessibility problems but won't solve the most in-depth issues that require the use of assistive technologies or accessibility software.  This is not a substitute.  This is a first step.

1. Go through an HTML validator.  If you pass, great.  If you fail, less than great.  Go back and figure out what you need to do to fix it and get a win.
2. Test accessible and inaccessible versions of the CSS in IE text sizing.  
3. In Windows 7, go to "all control panels - ease of access center -  turn on high contrast."  White text on black will appear and all images will be suppressed.  This is a good way to test for readability for users who may need high-contrast ATs.  This will also quickly help you identify any alt text that needs work.
4. Compatibility view in IE8 makes the browser act like IE7 and brings back "tool tips" behavior to see what the alt attributes are in your images.  You can also go into "Internet Options" in IE8 and turn off all of your images to see what manner of alt tag markup is there.
5. Check for your audio and video contents to have captions and/or transcripts.
6. Add your "skip navigation" links.  Tab through to test that your skip links go where you want to go.  Make sure your links are accessible through tabbing.  An antiquated technique for "skip nav" links was to put "skip to content" on a tiny invisible image that made the link accessible to screen readers but not to anyone else.  Nowadays many blind users use header navigation and don't rely on skip to links.  Does this mean we don't need them?  No!  Users who are keyboard-only, who may use wands or sticks or keyboard devices, need a way to skip through the navigation when they get to a new page, rather than having to tab through every single link.  If they can tab to a "skip nav" link, they need to be able to see it, so that they know where they are on the page, and where they can go from there.
7. Make sure the text of your link is clear enough that a user could at least guess at where it's taking them solely by reading that (and none of the surrounding non-linked text.)
8. If you are using interactive element in a form that doesn't look like a traditional form element, make sure the user can tab to it.  If nothing else, try assigning a "tabindex" value to it.
9. Label your form fields.  In many browsers, if you click on a label that has been formatted properly, the cursor goes immediately into the corresponding form field.  If not, nothing happens, or the cursor gets misassociated.
10. PDF documents!  Open your document in Adobe Reader, save it as "accessible text" (that is, go to "File - Save as Text").  Now read through the exported text to make sure that all of the necessary information is there.  Acrobat Pro gives you the ability to give accessible markup but accessible text is a free goto for those developers who don't have Acrobat Pro.  Adobe Reader is free.  In Adobe Reader, there is a built-in feature in "Document - Accessibility Quick Check" touted to check a PDF's accessibility.  Don't trust this.  Quick Check tests two things; first, is there any text at all in the document?  This test only fails if you scanned an image of text (like photocopying a page out of a book) and embedded it in a PDF.  Secondly, it checks to see if any present text is not "tagged" for PDF accessibility.  If the second test fails, Quick Check will report that the text is not structured but that there is text there.  Beyond those two things, Quick Check will give you the OK, but this is incomplete.  Images without alt text will be ignored, data tables that aren't scoped will be problematic.  Fields in a form in PDF need to have a tool tip in order to be read by a screen reader.  It won't read form labels or anything that appears to act as one.

• This is not the end of testing, but the beginning.

"Bigger and Better: Accessible Music-Reading Solution for Low Vision Musicians" by William McCann

Abstract:

Low vision musicians have tried all kinds of methods to permit them to read printed music notation. There are those who have magnified the original score so much through photocopying that the resulting sheets of music are too big to stay on their music stand.

Dancing Dots introduces a high-tech but simple solution made just for the low vision player. The music displays on a flat-panel monitor which can be mounted on a music stand. The notation can be magnified from 1.5 to 10 times the original size. Using a foot pedal, users can advance or move back through the score. A focus rectangle keeps the reader’s eye focused on the current measure. Third-party magnification programs like ZoomText and MAGic are used for reading dialogs and menus.

If one uses a touch tablet PC, one can even mark up the print score using a stylus just as 20-20 musicians use a pencil on a hardcopy score. The low vision player simply marks his score and, when the file is saved, the marking gets saved with it. When the file opened again, the mark appears in its place. Markings even resize in proportion to changes in magnification zoom levels.

My notes:

• You can control contrast and zoom in Zoomtext or Magic.
• Lime uses MusicXML to bring in music data. 
• Through no fault of the speaker's there were some technical difficulties that made the demo difficult to follow and excluded certain parts of it.  However, typically a sighted musician prepares the music, one with low vision or complete vision, and gets it into the format for the software.  Auto-prepared music may have issues (ie, a half note may be read as a quarter note, etc) so it helps if the blind or low vision musician using the software has a knowledge of music to begin with.

"Create Accessible Websites: What to do, what to ask for" by Katherine Lynch (that's me!)

Abstract:

This presentation will explain each of the roles involved in the accessibility process, from user agents, to developers, to their authoring tools. Common pitfalls that each of these components suffer from will be addressed, and tips for ensuring that each component helps provide a fair user experience will be given. The WCAG 2.0 Recommendation will also be addressed. Examples of coding solutions and best practices for meeting levels of compliance for sites and applications, based on the Recommendation, will also be provided. This presentation will help people who control web content provide more and better services for users with disabilities.

With new technology comes new accessibility problems and solutions. These accessibility issues impact web users of all ages, with any disability, including limited vision, hearing, speech, movement, cognition, photosensitivity, and learning. The WCAG 2.0 Recommendation provides techniques for solving these new accessibility problems that exist for building web pages and applications. It also sheds new light on denser past, though still viable, solutions to web accessibility issues. Additionally, authoring tools and user agents are being upgraded or replaced more and more frequently. Some are being built to accommodate new, exciting technologies but at the cost of accessibility. However, there are good, robust accessibility components out there that work with new technology instead of against it, and there are steps that developers can take to encourage accessibility upgrades and fixes in the tools that they already use and need. This presentation will detail research into some of the best authoring tools and user agents available for using and building to the web. Paths to communication and steps developers can take to encourage better accessibility support in these tools will also be highlighted, and details of the work going into helping Drupal v.7 strive to be the first out-of-box web accessible CMS will also be related. Finally, clear, precise steps for improving accessibility along the lines of WCAG 2.0 in web pages and applications will be delivered. Attendees will walk away not only with a renewed sense of community in the field of web accessibility, but also with directly-applicable ideas for improving accessibility in their own pages and applications.

My notes:

I presented on creating accessible websites through the use of WCAG 2.0 guidelines and techniques, as well as tested human techniques.  My presentation gave an overview of what WCAG 2.0 provides, as well as its pitfalls.  While the document is an invaluable resource for designing accessible software for the web, it is by no means a one-stop shop. 

For starters, the WCAG 2.0 document itself is short and readable, but for laymen, requires some further reading in the form of techniques, glossaries, and explanations.  Additionally, developers have been able to set a base of web technologies that they assume all users to their sites will have, which works very well except when this right is abused.  And finally, in an effort to keep from getting out of date too fast, the WCAG 2.0 document attempts to match its guidelines to "existing and future technologies," which means that many of the guidelines are broad, sanitized, and generalized, too much so for a developer trying to code out a Flash application (oh, the short answer: off the bat, Flash isn't accessible.  If you can do it without Flash, at least consider that) or HTML, PHP, and some Javascript.

However, there are usable techniques that can be inferred from WCAG 2.0 and its surrounding documents.  The surrounding documents do have a large number of specific tips and techniques that developers can use for making accessible sites and promoting accessible content.  My presentation extracted some of these (see my documents for content writers, designers, and programmers in the Technology Writings section for similar content) and highlighted many techniques I have discovered in the course of my own work and research.

The bottom line: don't get bogged down on technicalities.  Remember the user is a human and remember that you are human too.  Extract the tips and techniques that make the most sense for you, your authors, and your users.  Create sites and content that are usable by people, all people.

In closing

ATIA as a whole helped to personify usability and accessibility issues for users of all ages and abilities.  The presentations ranged from personal accounts, to software demos, to theory discussions, to formalized reports of governmental regulations.  The exhibition floor was packed with demos of technologies to help individuals with disabilities access the web and the world in a variety of ways.  Altogether, it was a thoroughly inspiring conference, and well-illustrated the importance of making information as it is available today, available to everyone.