This standard provides guidelines for designing web content authoring tools that are both more accessible to authors with disabilities (Part A) and designed to enable, support, and promote the production of more accessible web content by all authors.
I’ve (Greg Kraus, NCSU) developed a tool to help analyze text color contrast problems for text in images, over top of gradients, and in PDF documents. It’s available as a Chrome Extension. Feel free to use it and if you have any feedback I’d greatly appreciate it.
Download from the Chrome Store:
Provided by Sean Keegan, Stanford University
This position oversees and directs the University’s/institution’s accessibility policies and enforcement:
Chief Info Accessibility Officer
Office of Enterprise Technology
The Chief Information Accessibility Officer (CIAO):
- Convenes the Technology Advisory Board;
- Is the point person and champion for accessibility implementation within state government;
- Makes recommendations on legislation;
- Identifies, drafts, implements policy needed to meet accessibility standards;
- Identifies ways to integrate accessibility into current or new State processes;
- Is an ex officio member of governance groups ensuring that accessibility is appropriately considered;
- Works with the IT program to include accessibility standards in the new consolidated environment;
- Initiates and oversees an accessibility implementation program;
- Works with the appropriate enterprise and agency leadership to communicate the reasons for accessibility, and provide cost effective training across state government;
- Oversees accessibility content on web page;
- Stays current with changes to Section 508 and WCAG and trends in accessibility;
- Makes presentations on accessibility and the State’s accessibility implementation program to a wide variety of audiences. – Initiates and oversees an accessibility implementation program
- Using best practices for program documentation; Identifies, measures, and reports on progress and benefits achieved by the program;
- Manages the budget provided by the legislature;
- Creates and implements and accessibility communication plan;
- Status reporting, including annual report to the legislature.
This position requires all of the following:
- Section 508 and WCAG 2.0 Accessibility standards;
- Change management principles and methodologies;
- Public sector procurement processes;
- Familiar with all aspects of IT including hardware, software, web and application methodologies, and service delivery processes.
- Excellent verbal and written communication;
- Demonstrated leadership skills;
- Ability to relate to a wide spectrum of stakeholders;
- Ability to interpret and apply technology accessibility standards to specific technical and business requirements.
- Program and/or project management experience;
- Business analysis OR development experience in an application/web development environment.
- Policy and legislative experience.
Provided by Sean Keegan, Stanford University 10/19/2013
This job description is for a basic Web Accessibility position for Higher Education.
To provide central oversight, technical leadership, expert guidance, coordination, and support to the institution’s departments and programs in their use of the web, with a focus on promoting, assessing, and maintaining web and information technology accessibility.
- Perform regular accessibility audits of institutional websites and web applications.
- Perform accessibility evaluations for websites and applications under consideration for purchase and deployment.
- Work with vendors to implement accessibility features for web applications and software.
- Evaluate accessibility of external platforms that host institutional content, such as YouTube.
- Troubleshoot, evaluate and recommend assistive software and hardware.
- Establish guidelines, best practices and standards related to designing and maintaining accessible websites, IT software systems and online materials.
- Work in collaboration with the IT services and the other departments.
Outreach and Training
- Develop and implement outreach and training for web designers, developers and content providers. This person will also be a resource for faculty who are using the web to deliver instructional materials.
- Train clients on using accessibility monitoring software and assist in identifying strategies and solutions for IT accessibility.
- Develop webinars/online training materials.
- Develop and implement training on accessibility standards to a wide variety of audiences.
Design and Production
- Work with colleagues in the institution’s web services to develop accessible templates and tools for web production.
- Oversee captioning resources for providing information regarding captioning videos published on institutional websites.
- Identify, implement and oversee tools for monitoring website accessibility.
- Maintain the institution’s Web accessibility website.
- Create accessibility reports and presentations as needed.
Skills & Knowledge
- Extensive knowledge and experience with assistive technologies (JAWS, VoiceOver, Dragon NaturallySpeaking).
- Extensive knowledge and experience with WCAG 2.0 accessibility standards and guidelines.
- Experience with accessibility audit and quality assurance tools and processes.
- Familiarity with scripting languages desirable (PHP, JS).
- Strong organizational and project management skills.
- Effective written and oral communication skills.
- Demonstrated ability to effectively and independently lead projects to completion.
- Knowledge of disability law including but not limited to the Americans with Disabilities Act (ADA), Section 504 of the Rehabilitation Act (Section 504).
- Four years of web design and production experience on a web development team.
- Three years of web accessibility analysis, design, and development experience.
- Experience working effectively in highly collaborative, team oriented environments.
- Experience in a higher education environment preferable.
- Bachelor’s degree in Information or Graphic Design, Human-Computer Interaction or related field, or bachelor’s degree in another field and three years of experience.
- Master’s degree preferred.
Came across this URL and knew I would be referencing it quite a bit for updated web technologies.
Lay-person’s explanation of the WCAG 2.0 conformance levels along with a brief history of the WCAG 1.0 and 2.0 requirements.
University of Washington’s DO-IT introductory video on web accessibility that discusses how users interact with web resources with adaptive technology. The video in itself serves as a wonderful example of accessibility with prompting and captioning for users with hearing disabilities.
YouTube Link: http://www.youtube.com/watch?v=MO2gpA91fR8&sns=em
*Courtesy of the UC EALT
This list ranks the top 10 accessibility issues found in a survey of 8 major UC websites. They are ranked by a “Priority” measurement, which aggregates the impact of an issue on disabled users, the frequency with which it occurs, and the expected difficulty of fixing it. For example, a problem that would be difficult to correct that has a minor effect on visitors would be ranked lower than one that is easier to correct, or has a significant effect.
Because of the nature of automated testing, most of the issues identified have the greatest impact on two major groups:
- Blind and low-vision users, who use a Screen Reading program to read the contents of a web page to them (“Screen Reader users”)
- Users with motor control disabilities, who have difficulty using a mouse or cannot use a mouse at all, and rely on a keyboard or alternative input device (“Keyboard-only users”)
- Provide explicit labels for form fields (6 sites) – Without a properly identified label, a screen-reader user may not know what information is being requested, preventing them from using a form. A label also provides a larger area to click, for users with difficulties using a mouse. For example: Name: <label for=“name”>Name:</label> <input type=“text” name=“name” id=“name” />
- Provide alternative text for images (5 sites) – Images often include information crucial for understanding a website, but any information in the image is lost to screen reader users. The Alt tag serves two functions: Convey information not found in text elsewhere on the page, and when used in a functional element such as a link or button, provide text describing the element’s function. Images that don’t need alternative text (those that are merely decorative, or are redundant with other page text) must have a blank (alt=“”) attribute.
- Ensure headers and cells are properly associated (7 sites)
- Ensure table headers are used in a valid fashion (7 sites) – Data tables generally include a lot of information in a very small space. While sighted users can look at a table and infer headers from their position or color, a screen reader does not have the same context. If headers are properly marked up as column headers (<th scope=“col”>) or row headers (<th scope=“row”>), a screen reader can read the headers for each cell. While they will often guess correctly for simple tables, for complex tables this becomes more difficult.For example, even if this table contained hundreds of commodities and dozens of data about each, a user could determine that $7.76 is the price per bushel of corn:<table summary=“Commodity Prices”>
<tr><th scope=“col”>Commodity</th><th scope=“col”>Price</th></tr>
<tr><th scope=“row”>Corn, US$ per bushel</th><td>7.76</td></tr>
- Ensure the language of a document is set (4 sites) – This tells a screen reader how to pronounce words. If the language is not set on a page, screen readers will assume the language of the user, which would make the text unintelligible to a visitor from another country. Simply start the document with: <html lang=“en”>
- Ensure frame titles are meaningful (3 sites) – When a document has frames, screen reader users select a frame to read using only the Title attribute to distinguish between the frames. Meaningful titles like “Main Menu” and “Content” allow a user to navigate the page. Example:<iframe src=“/includes/menu.shtml” name=“f_mm” Title=“Main Menu”/>
- Ensure heading elements are properly ordered (5 sites)
All documents should use H1, H2, etc. tags to identify sections of a document. This helps ensure that a document is understandable to all users by breaking it into clearly identified chunks, and particularly helps users with cognitive impairments such as dyslexia or short-term memory loss to maintain context. Screen reader users can also use headings to find the relevant portion of a page also can use them, similarly to how a sighted user scans a page. However, if the headings are not organized hierarchically (i.e. if headings skip levels), screen reader users may not know the lower levels exist, decreasing the page’s usefulness.
<h3>Man Bites Dog!</h3>
<p>A local man grew tired of a meandering mutt, and …. <p>
<h4>Dog claims attack was unprovoked</h4>
- Provide valid, concise, and meaningful alternative text for image buttons (2 sites) – Buttons are labeled with their action – e.g. “Delete” or “Save”. When images are used for these buttons, screen reader users can’t tell which button to use – which could clearly be disastrous in this example! Add an alt tag with the same text (alt=“Save”) to the button to fix this.
- Ensure lists for indentation are not used (3 sites) – HTML tags should only be used for their semantic meaning, not for their appearance. In this issue, a list tag (<ul> or <ol>) should be used only to display a list of items in <li> tags. Instead, it may be incorrectly used to indent content. This can cause screen readers to describe the content in a way that is confusing to users. Instead, use CSS styles to indent content. Example: <p style=“margin-left: 2em”>…. </p>
How to Meet WCAG 2.0 Requirements – http://www.w3.org/WAI/WCAG20/quickref/
(3:14:25 PM) Shawn Pullum: http://www.htmldog.com/articles/suckerfish/dropdowns/
(3:25:44 PM) Shawn Pullum: hey
(3:25:45 PM) Shawn Pullum: http://simplyaccessible.com/examples/css-menu/option-3/
(3:25:55 PM) Shawn Pullum: this is another example of the same thing we did if you want to check it
(3:26:09 PM) Shawn Pullum: if this one works, maybe we can adapt its techniques
(3:43:50 PM) firstname.lastname@example.org/e39e18de: That 2nd technique works like a charm. It doesn’t let the user use arrow-keys but you can tab through all the entries.
(3:46:18 PM) Shawn Pullum: option 2?
(3:46:27 PM) email@example.com/e39e18de: yes
(3:46:31 PM) Shawn Pullum: http://simplyaccessible.com/examples/css-menu/option-2/
(3:46:39 PM) Shawn Pullum: there are a few of them
(3:46:40 PM) firstname.lastname@example.org/e39e18de: good explanation: http://learningtheworld.eu/2008/accessible-drop-down-menus/
(3:46:45 PM) Shawn Pullum: oh ko
(3:47:55 PM) Shawn Pullum: check this out
(3:47:56 PM) Shawn Pullum: http://simplyaccessible.com/?s=menu
(3:47:58 PM) email@example.com/e39e18de: both techniques seem to work
(3:47:59 PM) Shawn Pullum: there are a lot of options
(3:48:11 PM) Shawn Pullum: the focus thing
(3:48:30 PM) Shawn Pullum: how did it work with the new tool
(3:49:23 PM) firstname.lastname@example.org/e39e18de: Whats the focus thing? I did a search on the page and didn’t find anything
(3:50:11 PM) Shawn Pullum: http://simplyaccessible.com/wordpress/wp-content/themes/simply_accessible/stylesheets/screen.css