Accessible content writing starter kit | Access iQ Content author requirements On websites, content provides a big chunk of what makes your site successful. Whether you are in charge of writing, producing videos or commissioning others to produce content on your site, the accessibility of your content should always be a priority. Content management process Web content is dynamic and increasingly convergent. Creating web content that is accessible and complies with WCAG 2.0 is a process that involves the collaborative efforts of a web developer, designer and content author. A complete guide to web accessibility for content authors A practical premium resource for content authors that shows you how to comply with WCAG 2.0 Level AA. Five ways to improve the accessibility of your content How content is presented has a direct impact on the accessibility of a website. Accessible Word documents Creating Word documents that can be read by people of all abilities is just as important as creating accessible web content. Useful accessibility tools
Contrast Ratio Analyser Colour Contrast The old Accessibility Evaluation and Repair Tools (AERT) suggested algorithm for determining colour contrast now directs here. The AERT algorithm was never a recommendation, and WCAG 2.0's luminosity contrast algorithm is recommended instead. Success Criterion 1.4.3 of WCAG 2.0 requires the visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1; Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement. Analyse Luminosity Contrast Ratio
Accessible Form Validation with HTML5, WAI-ARIA, & jQuery Plugin By Paul J. Adam on May 25, 2012 Old browsers? Old AT? JavaScript to the rescue! Demo Form with HTML5, WAI-ARIA, & jQuery Validation (Default Settings) Demo Form with HTML5, WAI-ARIA, & jQuery Validation (Tweaked Settings) HTML5 and ARIA Have Limitations – JavaScript Does Not! Sure JavaScript has some limitations but really there are none when you code it with accessibility in mind. Adding the jQuery Validation Plugin jQuery is the dominant JavaScript framework on the web and can be declared the winner of the JS framework wars of the past years. jQuery’s motto is “Write Less, Do More”. It’s very simple to add jQuery Validation to any HTML form. The plugin picks up on our inputs with the HTML5 required attribute and by default will instead do its own JavaScript validation and not use HTML5. jQuery Validation Default Settings There are some issues with the default settings. So we have two problems so far with default settings. Tweaking jQuery Validation Options for the validate() method
Contrast Analyser & Accessibility About the Colour Contrast Analyser This native application (available for both Windows and Mac) allows you to evaluate the color visibility and contrast of foreground/background color combinations. It provides an initial pass/fail assessment against WCAG 2.0 color contrast success criteria. In addition, the Colour Contrast Analyser provides functionality to simulate certain visual conditions such as dichromatic color blindness (protanopia, deuteranopia, tritanopia) and cataracts. Details The Color Contrast Analyser was developed to facilitate the assessment of color combinations against WCAG 2.0: The Colour Contrast Analyser uses the following formula to determine contrast: where R, G and B are defined as: if RsRGB <= 0.03928 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4if GsRGB <= 0.03928 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4if BsRGB <= 0.03928 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4 and RsRGB, GsRGB, and BsRGB are defined as: Versions Windows
H71: Providing a description for groups of form controls using fieldset and legend elements | Techniques for WCAG 2.0 The objective of this technique is to provide a semantic grouping for related form controls. This allows users to understand the relationship of the controls and interact with the form more quickly and effectively. Form controls can be grouped by enclosing them within the fieldset element. All controls within a given fieldset are then related. The first element inside the fieldset must be a legend element, which provides a label or description for the group. Authors should avoid nesting fieldsets unnecessarily, as this can lead to confusion. Grouping controls is most important for related radio buttons and checkboxes. It can also be useful to group other sets of controls less tightly related than radio buttons and checkboxes. Authors sometimes avoid using the fieldset element because of the default display in the browser, which draws a border around the grouped controls. Resources are for information purposes only, no endorsement implied. Procedure Expected Results
Investigating the Accessibility and Usability of Job Application Web Sites for Blind Users - International Journal of Usability Studies Jonathan Lazar, Abiodun Olalere, and Brian Wentz Journal of Usability Studies, Volume 7, Issue 2, February 2012, pp. 68 - 87 Interventions It is important to note that there were a total of 34 interventions required, where participants asked for assistance in moving forward. Figure 1. Figure 2. The other 18 interventions occurred in situations where the participants asked for a suggestion to help them move forward. Previous | Next Visible Keyboard Focus Within the accessibility community, it is well-understood that visually indicating focus is a crucial step in ensuring access for sighted users who rely on their keyboard when interacting with the web. After all, it is explicitly listed in WCAG 2.0 as Success Criterion 2.4.7, [a]ny keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. But it has also been addressed repeatedly over the years by different people. Yet, providing visible keyboard focus is still not as widespread a practice as it should be. I am not at all a designer, but I do appreciate that in some cases the default focus rectangle might be seen to detract from a web page's visual design. Whether or not the default focus rectangle on links is removed using outline:none; or outline:0;, I think it's almost always a good idea to give keyboard users the same visual effect when they set focus to a link that mouse users get when they hover over a link with their cursor.
Building keyboard accessible dropdown menus – Interface - Blog of Web Communications at the University of Missouri When developing a dropdown menu for your site, it’s important not to assume that all your visitors will be navigating with a mouse. Some might be using the keyboard exclusively to navigate your website. Fortunately, enabling keyboard access is a relatively simple task. Here’s a typical dropdown menu example, one that follows the popular Suckerfish model: View Dropdown Menu Example It uses an unordered list, with second level lists for the dropdowns. Note that the additional ul li.hover ul rule is specifically for Internet Explorer 6, which unfortunately doesn’t support the :hover pseudo class on anything besides the <a> tag. So take a second look at the demo again, and instead of using a mouse, try using the tab key to go through the links. At most you’ll get an outline around any top level links that are selected, and no visual indication at all if one of the second level links are selected. Javascript to the Rescue Compliment :hover with :focus and :active and
Screen Reader User Survey #3 Results You are here: Home > WebAIM Projects > Screen Reader User Survey #3 Results Introduction In December 2010, WebAIM conducted a survey of preferences of screen reader users. A few disclaimers and notices: Totals may not equal 100% due to rounding. Demographics Disability Reported Screen Reader Proficiency Those who use screen readers due to a disability report themselves as being much more proficient with screen readers. 3% of those with disabilities considered their proficiency to be "Beginner" compared to 36% of those without disabilities. Internet Proficiency 61% of those who use screen readers due to a disability reported "Advanced" Internet proficiency compared to 86% of those without disabilities. Primary Screen Reader Most notable is a significant decline in primary usage of JAWS - down to 59.2% from 66.4% as reported in October 2009. Screen Readers Commonly Used The following chart shows changes in screen reader usage over time. Screen Reader Updates Browsers JavaScript Enabled Mobile Platforms
Accessible Dropdown Menus | Terrill Thompson A couple weeks ago at the 27th Annual CSUN International Technology and Persons with Disabilities Conference I gave a presentation on accessible dropdown menus. In that presentation, I walked through several examples of accessible menu techniques (and a few not-so-accessible ones). All the examples are available on my Dropdown Menus Test Page. Dropdown and flyout menus on websites are great for reducing clutter, simplifying page content, and providing a consistent navigation structure that (if done well) makes it easy to find content from anywhere on the site. Most dynamic menus depend on users being able to use a mouse. The quest for an accessible dynamic menu started as early as 2003, when Patrick Griffiths and Dan Webb published an article on A List Apart titled Suckerfish Dropdowns, proposing a menu system that was structured in HTML using a very simple nested unordered list, with a small amount of CSS and JavaScript that made it look and behave like a menu. Which model is best?
WAVE - Web Accessibility Evaluation Tool Shared Web Experiences: Barriers Common to Mobile Device Users and People with Disabilities This page describes many of the barriers that people with disabilities and people using mobile devices experience when interacting with web content, including web applications. It shows how these barriers are similarly addressed in W3C's Web Content Accessibility Guidelines (WCAG), Mobile Web Best Practices, and Mobile Web Application Best Practices. Background People with disabilities using computers have similar interaction limitations as people without disabilities who are using mobile devices. A comprehensive comparison between MWBP and WCAG is provided in Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG). Introduction The barriers on this page are grouped under four principles: perceivable, operable, understandable and robust. This page includes links to some relevant solutions in: The information below is also available in tabular format. Contents Perceivable Experiences discussed below are also available in tabular format. Text entry
Web Accessibility Testing: What Can be Tested and How | Karl Groves The Short Version Read this if you’re disinclined to read the entire list of specific WCAG Success Criterion and look at how each can be tested. If someone was to ask me what I consider to be my biggest strengths when it comes to accessibility, I’d say it is in testing. The thing about automatic testing is that there are some things which can be tested by machine testing quite reliably. With the above in mind, I’ve undertaken an exercise to determine exactly what can be tested. What does this mean? In short, it means that relying solely on automatic testing is probably a bad idea. The data These three tables detail how many items can be tested for using automated testing. How I arrived at this data The data presented above does not use or describe any information from any previous or current employer. Create a list of all WCAG Success Criterion, organized by Level. Some Caveats This list does not take into account the capabilities (or lack thereof) of any particular tool.