Friday, October 28, 2011

Accessible Web Design Overview

Rick Ells
UW-IT Web Guy
rells@uw.edu

AccessibleWeb@U

The Goals of Accessible Web Design

  • Be usable and intelligible to as many people as possible, including
    • People not able to use a mouse
    • People not navigating by touch
  • Be interpretable by assistive technologies
    • Structured
    • Semantic
    • Standard

Quick Evaluation

QE: headers

  • Are header elements being used semantically and are they organized hierarchically?
    • Pseudo headers created with bolding and sizing will not be recognized as headers
  • Check headers with the Web Developer toolbar Information item; pull it down to "View Document Outline".

QE: layout

  • Are tables being used for page layout?
    • Tables layout makes navigation much more complex
  • Check for tables with the Web Developer toolbar Outline item; pull down to "Outline Tables" and then "Table Cells".
  • Can content be interpreted intelligibly without layout (when CSS is turned off)?
    • Check content without layout with the Web Developer toolbar CSS item; pull down to "Disable Styles" and then "All Styles". Scroll down through bare-bones content; could you make sense of it in the sequence it is presented.

QE: alternative text

  <img src="gw.jpg" alt="George Washington">
Alternative text should be...
  • Accurate and equivalent
  • Be succinct
  • Not be redundant
  • Not use phrases like "image of..."
(Example from WebAIM (http://webaim.org)
Check alternative text with the Web Developer toolbar Images item; pull down to "Display Alt Attributes".

QE: labelling

The label element associates a name (for="first"with the input element with an id of that name (id="first")
<form action="form_action.asp" method="get">
  <label for="first">First name:</label> 
    <input type="text" name="fname" id="first"/><br />
  <label for="last">Last name:</label>
    <input type="text" name="lname" id="last" /><br />
  <input type="submit" value="Submit" />
</form>
Check labelling in a form with the Web Developer toolbar View Source item; Search in the source for "<label"

QE: colors

Color choice and the contrast between adjacent colors are important for determining reability. Contrast levels should be higher for small characters than for larger.
Evaluate colors and contrast with WCAG Contrast Checker. Check the "Text selector" and move your cursor around the page.

QE: semantic markup

Assistive technologies use semantic element types to help in presenting content.
Semantic:
<h2 style="font: medium bold verdana, sans-serif"> New Technology</h2>
Non-Semantic:
<div style="font: medium bold verdana, sans-serif"> New Technology</div>
There is nothing wrong with using DIVs for structural elements such as navigation, content, header, and footer.
Recognize that semantic element types have to do with structuring the content. Presentation (font size, font family, font size, etc.) of the types is controlled by the CSS.

QE: problem areas

  • Tables layout
  • Essential information in graphics without alt text
  • Content buried in scripts
    • Not using progressive enhancement methods
  • Content added after page load (Ajax)
    • ARIA roles needed to signal assistive technology which areas might receive updates

Accessibility at the UW

Accessibility Research at the UW

Web Accessibility Guidelines

Motivations

  • Personal
  • Community
  • Added value to our institution
  • Legal guidelines and requirements
  • Public relations
  • The baby-boomers are coming (and they have money)

The Legal Situation

  • Are UW Web sites a “public accomodation” under the Americans with Disabilities Act?
  • Do Washington state guidelines apply?
    http://ofm.wa.gov/ocio/policies/documents/1000g.pdf
  • Do you have a contractual agreement with students?
  • Do you have obligations to your funding sources?

Walk the Path

Welcome to the Basics 201 class! Today in class you will...
  1. Login with your UW NetID
  2. View a course page
  3. Download a PDF article
  4. Submit a question
  5. Use an online Web tool to take a test
  6. Watch a video

Where Are the Obstacles?

  • The login form might not have labels
  • The class Web page may not make use of semantic headings
  • The PDF article may be a scanned graphic image that assistive technology cannot interpret
  • The Ask a Professor IM interface may use Ajax, rewriting the display without a way for the assistive technology to know the rewrite has occurred
  • The online test tool may use tables layout
  • The video may not have captioning
  • Participating in the class requires that all steps can be done reasonably well.
  • Steps that are difficult are costs or "sacrifices" for the user, as they impose burdens that others in the class may not have to deal with.

Goals/Principles/Patterns

A good way to work toward comprehensive accessibility is to use the Goals/Principles/Patterns way of thinking.
  • Goals – Why are we doing this
  • Principles – How are we going to reach the goals
  • Patterns - What we are going to do to solve specific problems that come up as we implement the principles
  • As the patterns are chosen and developed, keeping the higher goals and principles in mind will encourage keeping accessibility in mind through the project
  • From Luke Wrobelski “Design Principles”, (http://www.lukew.com/ff/entry.asp?1292), which he derived from Service Oriented Architecture literature

Accessibility Goals

  • Inclusive
  • Effective
  • Efficient
  • Supportive

Accessibility Principles

We will design our Web services so they are…
  • Perceivable
  • Operable
  • Understandable
  • Robust

Accessibility Patterns

  • Adhere to standards
  • Use semantic elements
  • WCAG 2.0
  • Accessible Rich Internet Applications (ARIA)
  • ECMA Standard Scripting
  • Progressive enhancement methods in scripting

Content Management Systems

Most CMSs come out-of-the-box with good accessibility; don’t ruin it

Vendors Invest in Accessibility

HTML5

  • Capable of very good accessibility
  • Structured
  • Semantic
  • Roles
  • Validatable
  • HTML5 Accessibility
    http://html5accessibility.com/

Trends Going Forward

  • Rapid change
  • Mobile devices – smartphones to tablets – do it now, here, get immediate results
  • Web sites and apps need to work with wide range of sizes – smartphone, tablet, laptop, desktop
  • Pressure for simplification – Keep It Seriously Succinct

Mobile First

  • Start with designing for the mobile device, then supplement the design for laptops and desktops
  • Priority of mobile is rising
  • Mobile design forces you to focus
  • Mobile offers new capabilities (knows location, direction, talks to the cloud)
  • Mobile First – Luke Wroblewski
    http://www.abookapart.com/products/mobile-first

Responsive Web Design

Resources

Posted by at 2 comments:

Friday, July 08, 2011

Adobe PDF Accessibility

AccessibleWeb@U Meeting, June 30, 2011
  • Terrill Thompson, tft@uw.edu, Technology Accessibility Specialist
    • Slides are at http://staff.washington.edu/tft, along with slides of other presentations by Terrill
  • Lawsuits relating to accessibility
    • The goal of lawsuits is to clarify what is required by law
    • NFB actively advocating and services
      • Actually aiming a vendors, which are not covered by law, while public institutions are
      • California State University actively screening products to be sure they are accessible before allowing them to be purchased
        • CSU Accessible Electronic and Information Technology Procurement - http://www.calstate.edu/Accessibility/EIT_Procurement/
        • Accessible Technology Initiative, June 10, 2011 - http://www.calstate.edu/AcadAff/codedmemos/AA-2010-13.shtml
  • What makes an electronic document accessible?
    • Text alternatives to non-text content
    • Information, structure (good semantic markup), and relationships
      • Headings
      • Lists
      • Good structure gets passed on to assistive technology, which uses it to effectively present the information
    • HTML, Word, and PDF all support these features
    • Example: Accessible University Web site
      • http://staff.washington.edu/tft/talks/fileformats/syllabus.html
      • Because page is structured, voice browser (JAWS) can describe structure
        • CTRL- H lists headings
          • With JAWS you can jump by heading levels, thus using headings as a map of the page's content
        • JAWS identifies lists before speaking the list contents (if it is marked up as a lists)
    • Example: Word document - same page
      • To make a Word document accessible
        • Use the predefined styles for headings
        • To put alt text on an image - have alt text as one of the options
          • Recent versions of Word offer two fields, use the Description field (not the Title field)
          • Keep the alt text short and sweet
        • When making lists, use the list button
      • When you create a PDF, the structure can be passed to the PDF file by creating a "tagged PDF" file
        • Office 2010 will create a tagged PDF (When saving, click on options, and check the tagged markup box)
          • Mac Word does not generate tagged PDF. Have to go in afterwards with Adobe Acrobat Pro
          • In older versions of Office, can obtain add-ons that help to create tagged PDF
        • To create a tagged PDF, use "Save As PDF"
          • Using "Print" to a PDF will not created a tagged PDF
    • Three different types of PDFs
      • Image
      • Image with embedded fonts
        • Content could be all scrambled, has no tagging
      • Tagged (optimized for accessibility)
        • Tagged PDF has been around for a while, developed in response to federal requirement that files be accessible
    • To Create an Accessible PDF
      • Use an authoring tool that supports...
        • Creating documents with headings and subheadings
        • Adding alt text to images
        • Exporting to tagged PDF
      • Use these accessibility features anytime you create a document
      • Can tools be configured to be required to do the right thing?
        • Some HTML tools require alt text, headings, etc., but most other tools only offer the ability; you have to know about it and use it
    • Is sitechecker available to other campuses?
      • Can scan 50,000 pages
      • Contact Gina Hills about using the service
    • What tools support tagged PDF
      • Microsoft Word and Powerpoint 2010 (windows only)
        • Save As PDF
      • Microsoft Word and PowerPoint prior to 2010
        • Use Adobe Acrobat Pro
    • PDF Accessibility Check
      • Check whether document contents are an image
        • Is the document skewed?
        • Is the font clear or fuzzy
        • Try to select text on the page
        • If the content is skewed, the text fuzzy, or you cannot select text, the content is an image and will not be accessible
      • Check whether document is tagged
        • Using Acrobat Reader (a free tool)
          • Go to File > Properties (CTRL-D) and look for Tagged PDF
            • Even if says Yes, content may not be structured well enough
        • File > Properties (Ctrl-D) in any version of Acrobat; will say Tagged PDF: yes or no
      • Run an accessibility check
        • Using Adobe X Reader: Edit > Accessibility
        • Using Adobe X Pro: View > Tools > Accessiblity
    • PDF Accessibility Repair
      • Using Acrobat Pro
        • Recognize text (if needed)
          • Can you select words within the page
        • Tag document (if needed)
          • In Acrobat Pro: View > Tools > Accessibility
        • Touch up reading order
          • In Acrobat Pro, can change reading order of elements
        • Touch up structure (if needed)
          • Can scroll through document, select item, change tag for the items
          • Can add alt text to any element
        • Sometimes easier to delete all tagging and go through and retag it
        • Acrobat Pro has "Recognize Text" tool that scans images with text and generates text
      • Where to find Acrobat Pro's accessibility features
        • Recognize Text
          • View > Tools > Recognize Text
        • Read Out Loud (built-in screen reader; not very useful for blind users but may help to spot problems)
          • View > Read Outloud
        • Accessibility Tools
          • View > Tools > Accessibility
            • Prior to Adobe X: Advanced > Accessibility
  • Discussion
    • PDF is way overused
      • Many times people create PDF by default
      • PDF is useful if you need the document to look the same for all users
      • Otherwise likely to be better off creating document in HTML
Posted by at 4 comments:

Thursday, May 26, 2011

Mobile Accessibility


Mobile Accessibility
An open discussion
  • Accessibility Features
    • Mobile devices offer features to support users with various disabilities
      • Text zoom, screen zoom, cursor magnification and highlighting, on-screen keyboard, text-to-speech, audio, high visibility visual display modes
    • Apps can add specialized functionality
      • QuestVisual's Word Lens reads signs and translates them to a different language
        • http://questvisual.com/
      • Humanware's Oratio screen reader
        • http://www.humanware.com/en-usa/products/blindness/oratio_for_blackberry_smartphones/_details/id_131/oratio_for_blackberry_smartphones.html
  • The challenge of the touch interface
    • Smartphones and tablets generally are designed with "natural user interfaces"
      • By using touch gestures your can manipulate the user interface
    • What does touch interaction mean to people with various disabilities?
  • Current state of mobile accessibility
    • Summarized in an IBM presentation at CSUN 2011
      • http://www-03.ibm.com/able/news/downloads/IBM_Advancing_Mobile_Usability_for_Everyone_CSUN_2011.pdf
    • Smartphone market as of 8/2010 consists of 24% iPhone, 20% Android, 38% RIM (Blackberry)
    • iPhone has VoiceOver voice browser built in, other smartphones require a 3rd party app
    • iPhone supports ARIA, somewhat
    • iPhone and Android support HTML5, somewhat
    • Andoid offers tactile (haptic) feedback
  • Mobile Apps
    • Native apps
      • Run on the mobile device
      • Need to be written for specific device type using that devices toolset
      • Often draw content from information services elsewhere, such as RSS feeds
      • Native App Resources
        • Designing for Accessibility - Android Developers
          • http://developer.android.com/guide/practices/design/accessibility.html
        • iOS Accessibility
          • http://developer.apple.com/technologies/ios/accessibility.html
    • Web apps
      • Types of Web sites
        • Standard Web pages
          • Often have wide fixed widths, small fonts, low contrast, complex navigation
          • Difficult to use on a mobile; much zooming, scrolling, hitting the wrong links
        • Mobile friendly sites
          • Usually have flex designs, thorough use of relative size measures, large "tappable" links, simple navigation menus, simple hierarchical site structure
          • Could have a user interface for interaction (example: make a restaurant reservation), but takes some close attention to use it
        • Mobile optimized sites
          • Very simplified page design, flex design or auto-sizing to mobile screen size, very simple navigation, large tappable links and buttons.
          • If written with HTML5 can have many user interface features that are designed for use on mobiles, such as spinners, sliders, and forms that automatically evoke the appropriate keyboard
          • Could have functional interaction interfaces, to the extent care is taken to design for mobile devices
      • Can also draw content from Web services
      • May use HTML5
        • HTML5 is not standardized yet, variation among implementations
        • Many devices do not understand HTML5, but iPhones and recent Androids do, each in their own way
      • Different from mobile friendly Web pages, which are Web pages that display well and are reasonably usable on mobile browsers
        • Usually have flex designs, large tappable links, simple navigation
      • Web App Resources
        • Luke Wrobelwski
          • http://www.lukew.com/
        • Mobile Safari Web Application Tutorial
          • http://developer.apple.com/library/mac/#documentation/AppleApplications/Conceptual/Dashcode_UserGuide/Contents/Resources/en.lproj/MakingaWebApp/MakingaWebApp.html
  • iOS Native App Accessibility Support
    • Apple things supporting accessibility is good business
      • Apple's Commitment to Accessibility
        • http://www.apple.com/accessibility/
    • Matt Legend Gemmell, an independent Apple OSX and iOS developer, says it is easy to add accessibility support to your app
      • http://mattgemmell.com/2010/12/19/accessibility-for-iphone-and-ipad-apps
      • Built-in VoiceOver support in UIKit gives you 80% accessibility support
      • You can up that to 95% by configuring Interface Builder
      • You ccan up it to 100% support by using some "incredibly trivial methods"
        • Doubt was expressed about Deep Geeks who say something is trivially simple
  • Android Accessibility Support
    • Android Developer site says Androids have an accessibility layer that helps users navigate their devices more easily
      • http://developer.android.com/guide/practices/design/accessibility.html
    • Apps are specifically available for people who are blind or have low vision
      • Mobile Accessibility for Android - a suite of programs
        • http://www.codefactory.es/en/products.asp?id=415
Posted by at No comments:

Thursday, May 05, 2011

Defense Against the Dark Arts

Rick Ells, UW-IT
AccessibleWeb@U Meeting, April 28, 2011
  • Approach of this study
  • Some Terminology
    • Terminology from Service Oriented Architecture (SOA)
    • Goals – Strategic objectives
    • Principles – Design characteristics that support goals
    • Patterns – Solutions to common problems encountered when applying principles
  • Dark Art Spells and Incantations
    • Dark patterns are coding, design, and layout practices deliberately chosen to mislead the user into doing something other than what they came to do or giving up information they do not need to provide to achieve the purpose of their visit
  • So What Does This Have to Do With Accessibility?
    • A person working through assistive technology is even more vulnerable to being misled by dark patterns.
    • It is easy to inadvertantly engage in dark patterns, even if you are a white knight. Being aware of dark patterns can help you avoid them in your own work.
    • If you find yourself feeling indignant as you see these examples, think how you would feel if you had a disability that made it even more difficult to realize you were being manipulated or deceived.
  • Let Me Out!
    • Packaged fees, but no simple way to opt-out of specific fees in the package ("I do not want your service plan!")
    • Sign-up online, but canceling requires snail mail to corporate headquarters
    • Automatically signing you up for multiple email lists, while hiding how to select the ones you want or deselect the ones you do not want
  • Promises, Promises
    • You are invited to contribute your articles to the site for all to see, but does not mention that fees will be charged to people trying to see them.
    • Promising free access to information, but only giving it to people who register.
    • Saying the information you seek has been found, now please pay upfront to see it. So you pay and the information is not what you asked for.
  • Role Swapping
    • Placing one type of question where another typically is located
    • On software download pages, have other "Download" boxes for other software, without clear labelling to distinguish them from the download box of the product
    • Placing “Buy enhanced support plan” checkbox where “Send me marketing email” checkbox is usually located (down by submit button)
  • Unitless Offers
    • Recurring fee looks like a single fee
    • Displayed rate is only for first month, subsequent monthly rate is not shown
    • Ambiguous units
    • What is “Weekend rate”? Is that the rate for the whole weekend or for each day in the weekend?
  • Forced Continuity
    • Free trial silently rolls over into a periodic charge
    • Turning off the periodic charge requires going to some other site or even contacting the company by other means than the Web
  • Intuition Flipping
    • Reverse intuitive questions — “Check if you do not want extra insurance”
    • Opt flipping — Counter intuitive opt-in/opt-out questions — “Do you not want to receive our marketing messages”
  • Comparison Squelching
    • Price revealed only on the very last screen, perhaps after you have enter identification and credit card information
    • Only show rates without other fees that will be added
    • Only state prices in the form of “As low as…”
  • Whispered Exceptions
    • Exceptions and other qualifications of an offer are at the bottom of the page in low contrast text
    • Such text may be elsewhere in the site in an un-intuitive location, such as in the Statement of Terms and Conditions
  • Other Dark Art Power Practices
    • Discontinuities in decision trees so that choices important to the user are not encountered in the course of the interaction
    • Needed information not available in context
    • Misleading high visibility offers, hidden or low visibility qualifications on the offers
    • Massive default opt-ins
    • Hidden paywalls (you are in far enough that you do not want to quit, so you pay)
    • Burying choices that are disadvantageous to the site owner — out of sight, out of mind
  • White Art Practices
    • The WCAG 2.0 Four — Perceivable, Operable, Understandable, Robust
    • Empower — Let user know choices up-front so they can make informed choices
    • Decision Points — Present decision options clearly as a set
    • User Perspective — Support user expectations and habits
  • When Dark Patterns Are Used By Good Guys
    • The vendor may be aware that customers base their choices on incorrect understandings of the products. For example, many computer vendors do not put the CPU speed up front because now that many computers have multi-core processors, the CPU speed is not a good indicator of responsiveness of applications running on the computer.
    • The buying style of the vendor's customers may be less based on price and more based on the features of the product.
  • Defending Against the Dark Arts
    • WCAG and 508 as your technology foundation
    • Build the user interaction based on user expectations and perceptions
    • Keep key choices and information in-path and in-view
    • Give the user control of what is theirs
    • Simplicity, clarity, integrity
    • Design your site to support upfront negotiation of options, a square deal making it clear what has been chosen and its costs, and conclude with a handshake clarifying your commitments to your customer
Posted by at No comments:

Friday, April 01, 2011

Accessibility of Google Apps


Are Google Apps accessible enough to be relied on as the primary tools for your class or office?

The National Federation of the Blind (NFB) feels they are not and has asked the Department of Justice to investigate the reliance of New York University (NYU) and Northwestern University on Google apps as a violation of the civil rights of blind faculty and students. See...
  http://www.nfb.org/NewsBot.asp?MODE=VIEW&ID=771

The Chronicle of Higher Education had a short article on the topic that drew a lot of comments:
  http://chronicle.com/blogs/wiredcampus/colleges-discriminate-against-the-blind-with-google-apps-advocates-say/30394

Just how accessible are the various Google Apps? The Web2Access site, which evaluates interactive and collaborative e-learning tools, has been looking at the Google Apps. You can see their evaluations by going to the Web2Access site at...
    http://web2access.org.uk/
...and entering "google" in the search box. Readability and accessibility of text editors seem to be common weak points.

NFB has created a set of accessibility demonstration videos to show the kinds of problems they feel raise concern. You can see the videos at...
  http://www.nfb.org/nfb/googleaccessibilityvideos.asp

Google itself says it is committed to improving accessibility of its products. See...
  http://www.google.com/accessibility/products/
and
  http://www.google.com/accessibility/

One response to all this buzz is to let Google know how important accessibility is for the higher education environment. Back when Apple started pushing iTunes U, the California State University system (which has 23 campuses) refused to get on board because of serious accessibility problems with the iTunes interface. CSU even sent delegations to the Apple headquarters to advocate for improvements. Apple responded by making significant improvements. So, letting the vendor know how you feel can bring about real change.

Posted by at No comments:

Friday, March 04, 2011

Ted Drake of Yahoo Accessibility Lab

On Thursday, Yahoo's Ted Drake gave a presentation of CSE students about accessible design to kick off the coming week's HackU event (http://developer.yahoo.com/hacku/uw.html). Below are slightly cryptic notes of all the things Ted talked about

Accessibility Innovations and Challenges

Ted Drake, Yahoo Accessibility Lab
Facebook: YahooAccessibility
Yahoo Accessibility Lab Blog: http://yaccessibilityblog.com/
Drake's Blog: http://developer.yahoo.com/blogs/ydn/posts/author/tdrake/
Presentation: http://www.slideshare.net/7mary4/yahoo-hack-university-accessiblie-innovations-and-challenges
  • Yahoo
    • Has history of front end engineers working with back end engineers
    • Front end team has task of making it accessible
      • Web developers do most of the accessibility work
  • What is accessibility?
    • Addressing the needs of people with disabilities and their friends and families
    • About leveling the playing field
    • A major goal is to remove barriers - if your UI requires a mouse, you are already excluding people
    • Thinking about universal design, from the start, all the way through
      • You want designs that work for people whether they are abled or disabled
  • Who makes it accessible?
    • Lawsuit against Target for the inaccessibility of their
      commercial site design emphasizes the importance of accessible
      design
    • Accessibility is built by advocates and champions
      • Advocate refuses to go around things that are inadequate
      • Champions make accessible design happen
  • Make it accessible
    • Contrast - There are several good contrast evaluation tools
      out there, just search for "contrast checker"
    • Do not rely solely on color to convey meaning ("click on the red button")
    • Alt text for graphics needs to be explanatory, do not just repeat the headline
      • alt="" appropriate if image is decorative
      • ARIA has a role="presentation"
    • Title attribute - does not replace the Alt attribute
    • Images may be disabled
      • If using background images in CSS and you have text on that background,
        check for contrast of text on background without image. White lettering
        that no longer has a dark background is hard to read.
    • Off-screen text
      • A method sometimes used to make text available to people
        using screen readers but not visible to others by placing it
        way off screen
      • A problem in countries with text flow from right to left
    • Using wrong element type in HTML can confuse things. Use the most
      semantically correct element type
      • Example: using button for sign-in, then using anchor for cancel
        because you want cancel to look like a link
        • Confusing because cancel is an action, not a link to somewhere
        • Instead, make the cancel a button and style it as a link
      • ARIA role role="button" can be used to clarify things for the screen reader
    • Use th in tables for row and column headings
    • Command + allows you to zoom the page
      • Web designers are getting lazy about accessibility implications
      • A person who zooms in ends up with scroll bars
      • On Firefox, go to zoom text only (View -> Zoom - Zoom Text Only
      • Use YUI CSS packages
      • Proportional sizing is nice, but your situation may require fixed widths
    • Forms need labeling - every form field should have a text associated
      with it and the label attribute should be used to associate the field and
      the text.
    • ARIA
      • Can be used today
      • Works in almost all browsers
      • How to do it
        • Landmarks role="search"
        • Function role="button"
        • Labels aria-label="Search Term"
        • State aria-invalid="true"
    • HTML5
      • Firefox 4 will have the ability to use HTML5 roles, but most other browsers are not there yet
  • Innovative Solutions - Things student developers can work on
    • Traumatic brain injuries
      • Be careful about grayed out parts of your UI
      • Planning and execution assistant and trainer (PEAT)
        (http://www.brainaid.com/) manages timeline events, notifying
        patient of what needs to be done when
    • Short term memory loss hacks
      • Re-education tools
    • Cognitive disabilities
      • Syntax simplifiers
    • Presentation transformation
      • Readability.com
        • Simplifies presentation of Web pages
    • Icon identification of options
      • Enables visual based search, such as for phone numbers
        for people who have difficulty reading
    • Memory loss
      • What will help a person remember?
      • Mental games, seems to help short term memory loss
      • Journals
    • Non-visual people
      • Texture recognition
      • Converting visual to plain text
        • Photograph a street sign and it tells you want the sign says
      • Directions
        • Phone Wand tells you are going in the right directions
      • Games
        • Game for the blind that uses stereo sound
    • Deaf hacks
      • Sound detector, warns of sirens, etc.
      • Deaf twitter - take video, send it to twitter
    • Physical challenges
      • Web site scanner, moves through Web page section by section,
        bringing up sections that contain actions
        • Designed for someone who navigates with a single finger
      • Picture based communication devices
        • Buttons for specific messages (no, yes, help, etc.)
        • Need a service on the cloud that remembers your settings
    • Support social network
      • Giving feedback to support people
    • If it ain't broke, fix it anyway
      • Cool little apps can really enhance people's lives even
        if initially people are not sure they need them
Posted by at No comments:

Friday, January 28, 2011

The Federal Rulemaking Process

AccessibleWeb@U Meeting — January 27, 2011
  • Rolf Johnson
    • Assistant Attorney General in the UW Division of the Attorney General's Office (http://uw.edu/admin/ago/) - Guest Speaker
  • Web Accessibility & The Proposed New DOJ Regulations: The Federal Rulemaking Process
    • Presentation available at http://uw.edu/accessibility/accessibleweb/rolfbj_rule_process.pdf
    • Summary
      • Positive law heirarchy
        • Constitutions
          • Written at broad level of abstraction
        • Statutes
          • Also written at broad level
          • May give agency specific authorities
            • DOJ is elaborating on what the ADA means and how it works
            • In this case Department of Justice has authority to make rules
        • Regulations
          • Legislative - implementing statutes
          • Non-legislative - guidance
            • State how laws will be interpreted
            • Policy statements - how the agency intends to exercise its discretionaly authority
          • Management and procedural
        • Legistative rules require Administrative Procedures Act (APA) process
          • These rules often called regulations
      • APA process generally
        • APA rulemaking also called "informal" or "notice-and-comment" rulemaking
        • Basic APA rulemaking rpcoess
          • NPRM - Notice of Proposed Rulemaking
        • Other Procedures
          • ANPRM - Advanced Notice of Proposed Rulemaking
          • SNPRM - Supplemental Notice of Proposed Rulemaking
          • IFR - Interim Final Rule
      • ADA Design Standards Revision
        • General physical and architectural standards were updated first
        • Timeline
          • Sept. 30, 2004 - ANRPM published
          • June 17, 2008 - NPRM published
          • September 15, 2010 - final rule published
      • Proposed Web Accessibility Rules
        • Results of comments received during ADA design standards
          • June 26, 2010 - ANPRM published
          • Nov - Jan 2010/11 - Three hearings held
          • Jan 24 2011 - ANPRM comment period closed
          • Jan 2012 - NPRM to be published
            • Typically comment period is 60-90 days
          • ??? - NPRM comment period closes
            • Nothing dictates that rules must be issued on any fixed timeline
          • ??? - final rule published
            • Maybe sometime in mid-2013
            • 6 months later - New rule goes into effect for new pages
            • Two years later - Rules go into effect for old pages and sites
  • Discussion
    • Interesting aspects of the ANPRM
      • Rules will apply to the UW both through ADA Title II in that we are a state entity and through Title III in that we are a public accomodation
      • Limitations of responsiblity
        • Not responsible for content posted or uploaded to site by persons outside or your control
        • Do not cover informal or occasional trading, selling or bartering, but would cover larger commercial enterprises
        • Not responsible for accessibility of sites that are linked to, but would be responsible if using the services on those sites are required to successfully use your site
          • Credit card transitions are often done by external services - are the service providers you are using accessible?
      • Final rules are not likely to be in place before mid-2013, possibly later than that
        • Once they are in place, there will be additional time to bring your sites into compliance
        • DOJ does not have to follow a fixed timeline. They may decide that the proposed rules are not practical and not release any rules.
    • Enforcement
      • Complaint based
      • Proactive enforcement not likely for a while
    • DOJ already assumes we are covered by ADA requirements under Section 504 of the Rehabilitation Act
    • Cloud services
      • To the extent we use cloud services to provide services, we become responsible for whether the cloud service is accessible
      • Typically we deal with accessibility, security, and privacy of cloud services through contracts
      • Language about accessibility should be in any contract we have
        • Including indemnification clause
        • Examples of language that should be in procurement contracts can be found at http://www.washington.edu/accessibility/procurement.html
    • It is up to us how strongly we work for accessibility, at least at the moment
      • The ADA already applies to us through Section 504
      • National Federal for the Blind is trying to build up case law relating to accessibility in higher education
      • Expectation of accessibility is a rising tide, more and more people thinking about it
        • It is a dormant liability out there we need to be aware of
        • How big is the danger?
          • Bad publicity
          • Lawsuits
          • Not delivering a quality work or education experience
      • AG's office was pleased to see us looking into this topic, they like the proactive energy
    • Will standards apply to distance learning programs the UW offers?
      • There is no out, exceptions are rare, so yes, our distance learning programs are covered
      • Rules do not seem very granular in the details
    • The UW comes under Title II, public accomdation talk is about Title III
      • General saying "are you a public accomodation, if yes, then this applies to you"
    • Risk management
      • Taking steps to avoid possibilities of suits, enforcement actions, bad publicity
      • What is the risk before the rules are in place
        • Not a huge risk, certainly a rising one
      • Core question is "what will the standards be?"
        • In the ANPRM, DOJ seems to be basically asking "is this practical, will people really be able to do this stuff"
        • The current somewhat vague situation means we are less likely to be sued now than in the future when more specific rules are in place
        • Complying with all the WCAG 2 Level AAA is very difficult
          • Jim Thatcher recommends WCAG2 Level A
          • If there is uninimity on level A, we should do it now simply as good professional practice
      • When people come looking for information that might be used in a lawsuit
        • Worth thinking about how we respond to such requests
          • Might be good to view such inquiries as the equivalent to discovery events; pass the request on to appropriate authorities
    • What should our general strategy be?
      • Not good to be an outlier, more likely to be targeted
        • Our overall compliance should be as good as our peers
      • Enforcing standards only one method
        • May actually make us more vulnerable because we may be held to our own standards
      • Encourage accessible design as a basic part of professional competence
        • Be professionally proactive and bring our stuff into compliance with WCAG 2.0 Level A
          • See http://webaim.org/standards/wcag/checklist, look for the success criteria that say Level A
        • Encourage competition and cooperation among peers
      • Recognize that accessible design makes things work for everyone
        • Lowers costs and hassles for all customers
      • Need to watch for discontinuities and black holes in the processes we expect people to participate in; one missing link can prevent them from using a much larger system
Posted by at No comments:
Subscribe to: Posts (Atom)