1. Building an Accessibility Initiative
Rob Carr, of the University of Oklahoma CCE-IT Digital Accessibility Center presented a case study in this session. The University of Oklahoma has 24,000 students with a centralized campus. They do not have a large accessibility community. The disability resource center consists of four people covering three campuses and serves 40 departments.Two percent of their students are registered with center. CCE-IT is funded by grant and contract work.
A user had an accessibility problem with their registration and payment system. So Rob:
- Went to conferences.
- Created a team.
- Set up meetings.
- Obtained leadership support. Legal action primed university administrators to be receptive to accessibility professionals.
- Added specific contract language to CFPs to hold vendors accountable for the accessibility of products that their university purchases.
- Now asks for and checks vendor VPATs (Voluntary Product Accessibility Templates). They can help determine what kind of accessibility problems can be expect.
Rob Carr quote:
Faculty and staff listen if the message is right. There are pockets of people throughout institutions that are passionate about accessibility. The difficulty is often tailoring your message to different audiences, figuring out who needs to be on board and sometimes how to get them there...Even if you are brand new to accessibility, you can still spearhead an effort if you are willing to take steps to find your voice, engage others on campus and, craft your message and find or create force multipliers to help you implement your plans.
Rob Carr's PowerPoint Handout is available for download.
Take-a-Way Message and Possible Action Items
UMD is ahead on a couple of fronts.
- This session reaffirmed the importance of having an AT Team that meets regularly.
- It also is reassuring that University of Minnesota is forward thinking in providing sample vendor contract language:
To ensure that the requirements are satisfied, it is Recommended that each contract signed with a software vendor contain the provision set forth below or substantially similar language:
"Vendor hereby warrants that the products or services to be provided under this agreement comply with the University of Minnesota accessibility requirements. Vendor agrees to promptly respond to and resolve any complaint regarding accessibility of its products or services which is brought to its attention. Vendor further agrees to indemnify and hold harmless the University of Minnesota or any university entity using the vendor's products or services from any claim arising out of its failure to comply with the aforesaid requirements. Failure to comply with these requirements shall constitute a breach and be grounds for termination of this agreement.
A possible action item might be to help UMD to make sure our contracts have solid language that holds vendors accountable for the accessibility of their products and services.
- Could purchasing help by add a boilerplate clause to UMD contracts?
- Maybe a newsletter article to help make people aware of the existing language and VPATS.
2. How Accessible Are Google Apps?
In this session Greg Kraus of North Carolina University presented information on Google Apps accessibility. The Access Technology Higher Education Network (ATHEN) Google Apps Accessibility Interest Group has been collaborating on this project.
National Federation of the Blind (NFB) Complaints Against Universities
On March 2011 the National Federation of the Blind (NFB) filed complaints with the U.S. Department of Justice against Northwestern University and New York University (plus four school districts in Oregon) for violating Section 504 and the ADA by adopting Google Apps.
On January 2012 the NFB informally declared that Google Apps are "not there yet".
ATHEN's Evaluations
ATHEN has completed Google Apps accessibility evaluations. Focus was on users accomplishing tasks (composing email, adding a guest to a meeting, reading a document etc.). The focus was on visual, mobile, and cognative disabilities. ATHEN discovered problems with Google waffling between two types of access models. Some screen reader users will want to interact with these apps the way they do with all other Web apps. There are conflicting keyboard combinations with AT. Using both models is required for the most accessible experience. Switching between the models is problematic for some AT users. There are unvoiced actions from shortcut keys and lots of keyboard shortcuts to remember. There is a feature lag in alternative views as well as features missing.
Google Docs Evaluation (October 2011):
Assistive Technology | Grade |
---|---|
High Contrast OSX | C = a user can perform many functions, but must rely on non-prescribed methods of interacting with the application |
High Contrast Windows | D = a user can perform some basic functions, but most functions are unavailable or there are other significant problems |
JAWS | D = a user can perform some basic functions, but most functions are unavailable or there are other significant problems |
ChromeVox | D = a user can perform some basic functions, but most functions are unavailable or there are other significant problems |
Keyboard Only | C = a user can perform many functions, but must rely on non-prescribed methods of interacting with the application |
Read-Write Gold | D = a user can perform some basic functions, but most functions are unavailable or there are other significant problems |
Zoom-Text | A- = a user can (almost) fully use all functions of the application |
Dragon Naturally Speaking | F = a user cannot use even basic functions of the application |
General Problems with Google Docs
Keyboard focus is not always visible. Users need to "explore" the user interface outside the standard interaction methods. Over dependency on shortcut keys. Inconsistent implementation across browsers. No ability to apply established Web accessibility standards (alt text, table headers, MathML). Problems saving user preferences for assistive technology. Google isn't utilizing best practices in how assistive technologies interact with applications.
Report on Accessibility of Google Documents by ATHEN, October 2011
Gmail Evaluation (January-February 2012)
Assistive Technology | Grade |
---|---|
High Contrast OSX | A- |
High Contrast Windows | C |
JAWS | D |
ChromeVox | C |
Keyboard Only | B |
Read-Write Gold | A |
Zoom-Text | B |
Dragon Naturally Speaking | D |
Gmail basic HTML is generally better than standard view but labels are missing from forms. Gmail basic HTML has some fundamental accessibility errors that cannot make it an accessible alternative. Tab order is illogical. Rich text editing tools often are not available.
Calendar Evaluation (January-February 2012)
Assistive Technology | Grade |
---|---|
High Contrast OSX | A |
High Contrast Windows | D+ |
JAWS | D- |
ChromeVox | C |
Keyboard Only | B |
Read-Write Gold | A |
Zoom-Text | B |
Dragon Naturally Speaking | D- |
Only the Agenda view works for most (but not all) assistive technology. The accessibility features don't carry down to the meeting creation/edit screen. Often can't schedule a joint meeting.
Report on Accessibility of Gmail and Google Calendar by ATHEN, February 2012
Google Apps Improvements
Not there yet but making progress. The ongoing battle in the accessibility community is Chrome-only solutions vs. other assistive technologies. Google's ecosystem is designing functionality for chrome. They have developed a high contrast chrome extension and ChromeVox. Solutions are primarily delivered via extensions. Other vendors are making extensions i.e., Read & Write Gold (keyboard only) and Dragon Naturally Speaking.
They have written an Administrator Guide to Accessibility (PDF) and have provided apps accessibility update.
Dealing with Google Apps Accessibility Issues
- NC State University's Google Apps Accessibility Usage Guidelines
- Download Google Doc to Microsoft Office Bookmarklet - this automatically exports to word (however, headings are in plain text and need to be made real headings).
- Google Accessibility Feedback Form
- Accessibility Group @ Google Groups
- On Twitter: @googleaccess
- Greg Kraus' presentation slides
Take-a-Way Message and Possible Action Items
This session reaffirmed that Google apps are not yet accessible. The company is working to make them accessible and have the resources to do so. I think, that the cloud office suite will eventually become accessible (even if it is Chrome centric). We need to keep close watch on this.
In the mean time like NC State, the University of Minnesota already has standards that state the significant Google App Barriers in no uncertain terms. The U of M standard illuminates helpful best practices which may be a good addition to a newsletter article on the topic. They are:
- Consider the accessibility barriers of the Google App to be used and which types of disabilities may be effected.
- Allow the use of alternative software to accomplish the same tasks being done with Google Apps.
- Consider avoiding the use of Google Apps to provide access to educational material, if Google Apps is the only means of access.
- Consider a change in pedagogy to include small group participation, eliminating the need for an individual with a disability to interact directly with a Google app.
Greg Kraus' Google Doc to Microsoft Office Bookmarklet is a useful tool to convert inaccessible Google documents. That could also be added to the newsletter article on the topic of Google Apps Accessibility.
For further references consult the the Google section of Accessibility Page of the Web Design Reference site.
3. Options for Accessible Distance Education for Deaf and Hard of Hearing Students
In this session Cindy Camp and Michelle Swaney of Pepnet 2 shared their experiences and information on challenges and barriers faced by Deaf and Hard of Hearing (HoH) Students in Distance Education (DE). Pepnet 2 is a national center for improving post secondary outcomes for those who are deaf or HoH, including those with co-occurring disabilities.They are funded by the Department of Education.
Some of the Challenges/Barriers
- Disconnect between stakeholders
- Vendors with inaccessible products
- Inaccessible multimedia
- No transcript for audio
- No or poor captions for video or video clips
- Not providing the user control (captioning color/font/size)
- Not providing quality video
- Not providing quality video for Interpreting
- Timed tests
- Synchronous chats
Ideas to Help Avoid Problems
- Collaboration
- Collaborate with all stakeholders including students. Partner with others on and off campus
- Have a review process of distance classes to ensure their accessibility.
- Provide faculty with an accessibility checklist. Example: Advise students and instructors to use appropriate subject lines in discussion posts. Can be difficult for screen reader users to differentiate if each post has the same heading.
- Don't wait for a request for accommodations. Design classes to be accessible from the beginning.
- Vendors
- Ask vendors to actually demonstrate the accessibility features in the products they are selling.
- Include vendor contract language regarding upgrades to address the scenario for if/when a product "upgrade" actually makes a product inaccessible. If the new version is inaccessible then the vendor breaks the contract.
- Get an accessibility statement, which includes upgrades, from vendors in writing before buying.
- Multimedia accessibility
- Audio content needs to have a transcript.
- Video content needs to captioned.
- Transcripts
- A transcript should include speaker identification.
- Spelling, capitalization, and grammar must be correct.
- Punctuation follows standard rules, but also special rules unique to captioning.
- All essential sound effects should be included, either in words or symbols (e.g., 'buzz' or a music symbol).
- Captions
- Captions are only as good as the transcript.
- Should appear at approximately the same time as the audio is delivered.
- Should be equivalent in content to that of the audio, including speaker identification and sound effects.
- iTunes - captions must be embedded not a separate file.
- YouTube - transcripts can be uploaded and automatically time
synced. Do not use the automatic Google’s
automatic speech recognition technology to caption videos on
YouTube as it is poor quality.
- Caption Fail YouTube Channel: "Rhett and Link let YouTube closed captions interpret their original script, then act it out again"
- Captioning Key
- Captions are only as good as the transcript.
- Video
- Test. Test. Test. Determine and eliminate barriers, one problem at a time.
- Video Best Practices - Malaspina University-College
- Top Ten Digital Video Tips
- Web Video Guidelines - The University of Texas at Austin
- Video and Interpreting
- Slow down signing to avoid hand ghosts . Instructors may need to be cautioned as well.
- Background (no navy or black)
- Use good lighting
- Interpreter's clothing (maroon, green, brown- not navy or black it distorts the hands for signing)
- Placement
- Prior testing and signing into the session early
- Timed tests
- Do they really need to be timed?
- Are there other ways to assess a student's knowledge?
- Could the test be proctored?
- Synchronous chats
- Ask what the goal is. Could an asynchronous chat forum( threaded dissuasion) be used instead?
- Synchronous requirements defeat the purpose of an asynchronous class
- Be creative e.g., In a captioning class, have some students transcribe videos. Have others create signed videos from text transcripts.
Cindy Camp quote:
- Identify challenges in making distance education programs accessible for participants who are Deaf and Hard of Hearing.
- Identity successful ways to make an online distance program for students who are Deaf and Hard of Hearing.
Take-a-Way Message and Possible Action Items
This session reaffirmed that UMD is heading in a good direction with our captioning initiative. A low hanging fruit to pick would be to promote posting a link to transcripts along with captioned videos. Transcripts benefit not only the deaf-blind but also people with different learning styles.
When purchasing ask vendors to actually demonstrate the accessibility features of the products they are selling.
Consider adding vendor contract language regarding upgrades to the existing University of Minnesota standard to address the scenario for when a product "upgrade" actually makes a product inaccessible. If a new version of a product is inaccessible then the vendor breaks the contract.
Keynote by Derek Featherstone
Derek Featherstone has been an accessibility expert for quite some time. I think I first corresponded with him in 2000. Throughout his keynote Derek used a Star Wars theme and analogies as he often does.
Key Take-A-Way Quotes
Derek's opening:
In accessibility, if you don't believe, you fail.
Derek quoting Yoda:
Size matters not. Look at me. Judge me by my size, do you? That is why you fail.
Derek talking about Jedi mind tricks:
This is not the solution you're looking for.
Derek:
Disability is an amplifier for a usability problem.
Ground surface indicators are akin to HTML headings.
HTML is the only universally accessible format.
People won't always react positively to the decisions you've made. Live with it, correct it, and move on.
There will always be someone that knows more than you.
Look for inspiration based on what works and use that inspiration.
We accessibility folks have to take our skills and pass them on.
One solution does not fit all we are th rebel alliance.
IT Accessibility Policies and Practices in Higher Education: Research Findings
Terrill Thompson from the University of Washington presented this session.
In 2012 researchers at the University of Washington began work on a formal research project to acquire a better understanding of the types of strategies that higher education institutions are employing to improve their web and information technology accessibility. They developed a method for searching college and university websites for technology accessibility-related content and quantifying their findings, and they applied this method to a large sample of U.S. institutions across all Carnegie Classifications. Terrill presented some of the study.
Page Evaluation
Evaluated 31,701 pages for:
alt
attributeslabel
elements- Heading elements
lang
attributes- Accessible Rich Internet Applications (ARIA) landmark roles
Element and Attribute Findings
Element or Attribute | Percent of Pages |
---|---|
Heading elements | 77.9 % |
alt attribute |
60.4 % |
label elements |
39,8 % |
lang attributes |
37.3 % |
ARIA landmark roles | 3.3 % |
Overall 43.7 %
Examined PDFs
- One measure: Tagged?
- Searched for string /Marked true
- Manually checked 100 documents
PDF Findings
33.8 % were tagged. Manual inspection of a few PFDs revealed that some are accessible but many are not.
The large 33.8 percentage is likely due to Word 2010 for windows save as PDF is accessible tagged PDF. (However styles need to be used). Save as PDF is not accessible on MAC.
The Accessibility Conversation
- Searched for the word "accessibility" on university home pages
The Accessibility Conversation Finding
Approximate 100 institutions have zero results for the search term "web accessibility " or "technology accessibility ".
Existence of Web Technology Accessibility Policies
Manually reviewed policy results for:
- Formal stand alone policies
- Formal incorporated policies
- Standards or guidelines
- A general statement
Policy Findings
8.4% of higher education institutions in U.S. have accessibility policies.
Key Finding: Correlation Between Policy and Greater Accessibility
A correlation was found between institutions that have an accessibility policy and the conversation. Having a policy if nothing else raises the accessibility conversation at higher educational institutions. Formal standalone accessibility policies are related to greater accessibility.
The paper from this study is being peer reviewed and should be available early in 2013.
Take-a-Way Message and Possible Action Items
Because of the correlation found between having an accessibility link on a university home page and raising accessibility consciousness, our AT Team may want to consider asking the Campus Web Committee to add a link to an accessibility policy on the UMD home page.
ITSS is ahead of the curve as we already inject landmark roles into
our web pages via javascript. We could ask Andy to add landmark roles
to the UMD templates as this would increase accessibility and benefit
the full campus. (Either via javascript injection or better yet using
HTML5 where landmark role attributes are valid.) In addition we could
ask that add short text alternatives (alt
attributes) and
where appropriate long text alternatives (longdesc
attributes ) be added to images on the UMD home page.
User Testing with People with Disabilities
Kathy Wahlbin, President and Founder, of Interactive Accessibility presented this session. It provided general guidance regarding usability testing. She went over general usability testing principles, and methodology. Then she provided some tips on incorporating people with disabilities into user testing, which included the following:
- Test after accessibility guidelines have been set.
- Make sure the location is accessible or do it online in an accessible manner.
- Drawback of remote testing is having to rely on participants reporting accurately instead of direct observation.
- Use every specific tasks (not branching tasks)
- Recruit 3-5 users for each screen reader or other Assistive Technology
- It takes a long time to recruit participants.
- Pay participants ($200 is the norm).
- Observe what is not intuitive and ask about satisfaction.
- Report only facts.
- If you can't test, asked for feedback from people with disabilities. That will al least provide some information.
Take-a-Way Message and Possible Action Items
This session reaffirmed the same general usability testing information that I put together years ago in Web Site Usability Evaluations and Planning a Formal Usability Test: goals, tasks, scenarios, measures, participants, environment etc. ) I should keep it available as basic principles and methodology haven't changed.