« Flashforward Boston: SWX | Main | Flashforward Boston: Designing with Sound »

Flashforward Boston: Usability Approach to Accessibility

Rough draft of notes

Niqui Merret

Audience poll: Some people have done accessibility testing, but most have mot done so with disabled users.

Need to understand your users.

Accessibility is for everyone vs. technology or device. Focus on users with disabilities.

Accessibility in the real world, no technology is 100% accessible to all users. Aim to achieve best solution, maybe multiple technologies are needed. Combine Flash and HTML.

Definition of Accessible: To be able to be accessed. Want to break down barriers to accessing information.

Two main barriers:
Controls outside of Flash control: no tabbing between Flash and HTML site, wmode setting issues along with MSAA issues, MSAA didn't work with prior versions of Flash player, can't tell screen reader "I've made an update", can't set reading order on static textfields, Flash doesn't support voice over on Mac, Flash doesn't take high contrast settings on Windows.

Content and presentation barriers: stuff we build in that we need to think about (not everything needs to be accessible). Understand where the user is coming from. Screen reader users probably can't use mouse, need keyboard control.

Disability categories (these are all muddy and shouldn't be a taken as hard and fast):
visual (color blindness biggest issue), audio, motor, cognitive (good understand, foreign language).

Legal and General UK case study of accessibility and ROI.

Color and contrast (don't care about colors, need to distinguish content). Showing contrast demo with memoriaduo.com. Mac system settings has built in contrast control. Some tools available on other platforms. Don't talk about a color without a non-color cue ("Click on the green button") Provide tools to switch within your application if possible.

Size: Provide mens of controlling font size.

Keyboard Access: Provide logical structure. Flash accessibility dialog (easily set tab index). Focus highlighting is important if you have keyboard controls. Shortcuts make sense if someone is going to be using the site multiple times. Non visual users need to have them explained.

Audio: Provide textual or graphics of audio information. Using weebls-stuff.com videoas an example. Text on screen of audio lyrics. Harry Potter website is another good example.

Screen reader access: Auto next doesn't force update. Yahoo developer network has videos about screen readers and explanations from blind users and screen magnifier example. Set the name of buttons for non text buttons. Flash auto labels textual buttons. Specify reading order (tab index). Avoid using wmode.

Demo of Inspect tool part of Microsoft accessibility suite to show what is being sent to screen.

swffix.org Going to be best embedding technique, currently in public Alpha. Will replace SWFObject and UFO joint project.

http://www.adobe.com/accessibility/

http://blogs.adobe.com/accessibility/

How big is big enough for font size: Niqui recommends minimum of 11 or 12 for Arial. Font and context specific.

Standalone player and AIR don't communicate with MSAA.

Flash vs. AJAX accessibility. Flash is more accessible by default. osflash.org has AJAX aid which detects virtual buffer refresh. Easier to control visual output (contrast, fonts, etc.) in Flash.

Flash components can destroy tab ordering. Something on stage that that isn't labeled will throw off tab order. Best to set tab enabled to false.

Tags: accessibility flash flashforward2007boston