Expanding the web's potential for people with disabilities
Screen Reader User Survey #4
The fourth WebAIM screen reader user survey is now available at http://webaim.org/projects/screenreadersurvey4/. The survey results provide invaluable data for web developers, disability advocates, and standards bodies. Please take the survey and spread the word.
You can view the results of our previous surveys at:
Accessibility Certification: The Devil is in the Details
This past month WebAIM staff had an opportunity to attend CSUN 2012. As always, CSUN was a great opportunity to see what others are doing, share what we’ve been up to, and connect with good friends in the accessibility world. Prior to the conference, the Assistive Technology Industry Association (ATIA) hosted an all-day meeting to discuss the establishment of a society of accessibility professionals. As part of this meeting, I was asked to participate on a panel to discuss whether creating professional certification in accessibility would provide a solution or create a bigger problem in the field. The meeting itself, along with its focus, created quite a lot of discussion beforehand (e.g., Knowbility’s blog being only one of them) and afterward (What does it take to call yourself an accessibility expert? and Is there a need for a professional accessibility society?). We are all better for engaging in substantive discussions that impact accessibility outcomes.
We are currently in a chicken-and-egg market dilemma with respect to accessibility needs and professional skills. On the one hand we have employers saying that there are insufficient numbers of professionals in accessibility available for them to hire. Employers consider this a failure of training and contend that they should not be penalized for this reality or be required to hire people that simply don’t exist. Thus they don’t “require” accessibility skills upon hiring. Because of this, there is not a market requiring those skills.
On the other hand, there have been attempts to provide the field with training programs that produce accessibility professionals even when it is not apparent that there is a market for them. Many colleges and universities, both in the US and abroad, have created preservice training programs over the years with accessibility as a focal point. The programs are almost impossible to sustain over time as they are viewed as serving a small niche that is not valued (read: “required”) by employers, and have only a few students take advantage of the opportunity.
Thus the cycle continues with employers looking to the outputs of training programs and training programs looking to the needs and requirements of employers.
WebAIM is one of many groups who have had internal discussions for years on the merits and challenges inherent in professional certification. If it were an easy thing to accomplish I think we would have done so long ago. We do believe that the concept of accessibility certification would be a helpful way to ensure quality professional practice in the workforce. With that said, we also feel that there are at least six critical issues that need to be addressed before a professional certification would be valuable within the field. Each issue is briefly summarized below. As you can imagine, for us the devil is in the details.
It is critical that certification is intended for professionals from all sectors. Examples would include those from industry, government, commerce, education, NGO groups, and health care. If certification were to be customized to any small segment, it would lose the importance of broad applicability. Any employer should be able to turn to this certification as proof of skill level, and not skill level customized for the needs of a narrow constituency.
While most would agree with this premise, it comes into play as other issues are addressed, for example, when talking about funding a system of professional certification. While those in industry may have membership fees paid by their employer, such a practice is not allowable in education and most NGO’s. If the membership fee is a couple of hundred dollars a year this may be a non-issue, however, what could be the effect if it were $600 a year or more? I would predict that over time this organization would contain greater numbers of members from industry. If this were to happen what would be the impact to cross-sector applicability over time as the membership demands greater customization to their unique interests?
The certification that results from this effort must be based on an individual’s performance and not on attendance or completion of any training or education experience. While most would agree with this, we must consider plans for how performance-based appraisal would occur. For example, where do these activities take place? It is unlikely that a professional member group would host site-based testing opportunities all across the globe. Moreover the personnel seeking certification would likely expect asynchronous online testing to obtain certification. Yet such testing creates the very context that continues to rock the distance-education world. Namely, e-verification of the person who is taking the test or completing the tasks. To the extent that potential employers require certification – a desired goal to be sure – pressures may exist that could lead to practices antithetical to the verification of individual professional skills.
While we are talking about performance-based testing, there are several issues that affect quality testing as the basis for certification. Let us be clear, if this certification is used as any part of employment decisions, it must be rock solid; we would want it so even if not used in employment. Whatever is developed must contain the highest levels of both internal and external validity. Those not familiar with creating valid, robust testing items probably should not do so. Central to a quality test is a quality-testing standard. Stakeholders representing divergent sectors should create the specific testing standard and individuals with disabilities must be part of this group. Now don’t get me wrong, when I talk about testing standards my starting point is WCAG 2.0, as the international standard. However with that said, exactly what is being tested? What is the scope, depth, and diversity of this performance-based measure?
Here are examples of what I mean: Would we ask an individual to identify accessibility issues, repair an issue given to them, or create content free of issues? Since each of these requires a different level of skill we need to know what we want; With form labels mapping to 6 different success criteria within WCAG 2.0, which is tested? Or is each tested in some redundant fashion? Would we judge the use of ARIA for labeling to be OK if they could have used HTML?
As you can see, a great deal of thought must be brought to the specifics of the testing standards. We cannot afford to be reductionists, stating that we’ll test for WCAG 2.0. It is much more complicated than that.
We also think it vital that these testing standards are continuously developed as our understanding and use of technologies expand over time. Moreover, we feel strongly that any resulting testing specification would be publically available, at no cost. This is important so that preparation for certification could come from many sources, including the ability for an individual to prepare him or herself if they so choose. Public availability of the testing standards would also provide the opportunity for continuous feedback into the system and keep it relevant to the needs of professionals.
We feel that for accessibility certification to be taken seriously it needs to be operated by an existing respected independent professional organization and insured to do so. Any group with suspect motives, or one that springs up just to take on this initiative, would probably not get the needed participation or collaboration from those currently in the field. This group then needs to figure out who is evaluating the tests that come in from those seeking certification. Clearly, the personnel used to judge performance must, themselves, be beyond reproach in the field. Moreover, legal challenges to the operation of testing and certification are likely to follow as they have in just about every other professional certificate; this makes sense in the context of certification as a gate-keeper for some employment opportunities.
Costs need to be reasonable to attain, and maintain, certification. Everyone in this discussion agrees that there should be an initial certification with professional paths that would allow for continuation of certification in regular cycles. In other words, this should not be a one-shot deal. However, I have not heard anyone talk about the costs of doing this – both for the person who receives certification and the group who does the work to offer it. This will be important as cycles of continued certification are defined; for example, if you must pay to recertify every two years versus every five.
Finally, WebAIM believes that this certification process must be a living entity. Technologies and techniques change what it is that a professional does to ensure accessibility. The testing standards and the certification(s) themselves must reflect this fluidity. Failure to create a mechanism for continuous updates, or changes, to certification would be its ultimate death as the certificate would quickly be out of touch with what is needed in the field. With that said, would this require new performance-based testing or evidence of education on the matter, and in what cycles (e.g., 6 months, yearly)? Depending on the profession you choose to look at you’ll see different mechanisms. While many educators retain licensure by working in the field and obtaining continuing education credits, physicians who wish to use new surgical procedures must not only be trained, but undergo a practice-based evaluation. I suspect that some areas of the field are more like educators and others are more like surgeons.
WebAIM will continue to discuss these, and other, issues that pertain to professional certification in web accessibility, as they are important to the field. We invite you to make comments below. It is our hope that over the coming years, each issue will be resolved and we can all begin the work to help establish certification of professional skills in web accessibility.
Assistive Technology Experiment: High Contrast
Several months ago I decided to spend some time using a few common, but often overlooked, assistive technologies and then report on my experiences and insights. The first two posts of this series presented my recommendations on designing for users of ZoomText and Dragon NaturallySpeaking. As the final part of this series, I will cover the High Contrast options in Windows 7.
High contrast settings benefit users with low vision or other visual disabilities. The "High Contrast Themes" present in Windows change or invert web page background and text colors. To enable High Contrast in Windows 7, select the Start menu (Windows Key), enter "Contrast" in the search field, and select "Turn High Contrast on or off".
GIF and PNG images are commonly used on the web where a transparent background is necessary. This allows the image to be used where the background color may change, or may be a pattern or gradient. Unfortunately, these images are often used in a way that makes them unreadable when the background color is inverted or changed. An example of this issue can, unfortunately, be found on the current version of our own site. At the bottom of this page is a section that displays the logos for the Center for Persons with Disabilities and Utah State University (where WebAIM is housed). These logos are both GIFs with transparent backgrounds. While these logos are readable on the default white background, they become much less readable when the background of this page is changed to black, as shown below:
Contrast this with our own logo, which maintains readability:
The WebAIM oval has a white background, but the edges are transparent. The image blends into the background, yet remains readable in High Contrast Mode. A similar technique should be used on other images with transparent background – an opaque background should be applied to essential content, especially text.
Relying on color alone to convey meaning is typically avoided because it can make content inaccessible to users who have color blindness, as well as users who are blind. While this accessibility principle is well known, there are also times when color can be used in a way that may only present problems to users who rely on high contrast. For example, the following image is a screenshot of two headings, an <h2> and <h3>. The <h2> contains 15pt white text on a green background and the <h3> contains 14pt green text on a white background:
This is accessible to an individual who is blind, because a true heading structure is used, and to someone who is colorblind or has low vision because the colors and contrast are distinctive. But if you view this image in High Contrast Mode, the differences between the headings becomes much less clear:
While there is a slight difference in text size (which is not always the case when this technique is used), it is still very difficult to distinguish heading levels, especially if headings are separated by large amounts of text. In a case like this, the headings could be further differentiated by using indentation (like we do on the WebAIM site), style differences (e.g., font face, bold, italics), and a greater difference in font size.
CSS Background images are often used on websites in place of true images, especially for small icons or for elements that are repeated throughout the page. These images are typically hidden in High Contrast Mode. The good news is that this means that decorative background images will usually be hidden, simplifying the visual layout of the page and potentially enhancing accessibility. The bad news is that CSS images, including CSS sprites, that convey meaning will usually be completely invisible. There are several resources online that describe this issue in greater detail and provide recommendations for workarounds. Todd Kloots of Yahoo has written a great article titled Techniques for High-Contrast-Friendly Icons that includes links to several other resources on this topic.
I highly recommend testing web content in Windows High Contrast Mode. There is no special software to purchase (assuming you have access to the Windows operating system) and almost no learning curve, and It helps uncover accessibility issues that cannot easily be uncovered in another way. Testing with Windows High Contrast is especially important if you are using non-decorative CSS images.
High Contrast Modes differ by program and operating system. On Mac OSX, the High Contrast settings invert all the colors on the screen, including images. This same thing occurs in Windows when colors are inverted using the Magnifier program, or when using a screen magnifier such as ZoomText. It may be worthwhile to test your pages using a variety of programs or operating systems.
I want to highlight the importance of using true text over graphical text when possible. This was reinforced as I used ZoomText, Dragon, and now High Contrast Mode. This has been part of accessibility recommendations for years, and is included in WCAG 2.0 Level AA and AAA specifications. But it seems that the focus of this recommendation is often limited to the reduced readability of graphical text, especially as it is enlarged – something that is less significant due to the ability of modern browsers to enlarge images much more clearly. This is still an important reason to use true text rather than text in graphics, but there are ways graphical text can impact users with various disabilities. A few examples are listed below:
I am not recommending that graphical text be eliminated. There are many instances where images are still the best choice, or where limited CSS support makes the use of true text unrealistic. However, the use of true text has numerous accessibility benefits and should be implemented as often as possible.
WCAG Next
The Web Content Accessibility Guidelines 2.0 became a W3C Recommendation (code for “finalized specification”) in December 2008. I am proud to have my name listed as a contributor to WCAG 2.0. All of WebAIM’s current clients are working toward WCAG conformance. None of them are seriously considering only the antiquated Section 508, the update of which is perpetually stuck in bureaucratic delay tactics.
While WCAG 2.0 has been used to greatly enhance the accessibility of web content, it is not perfect. Its complexity and rather absurd terminologies, while generally necessary, decrease its approachability (and arguably accessibility) for many people. It is difficult to understand. WebAIM has provided a simplified WCAG checklist to help authors get started and to aid in evaluation of HTML documents. Accessibility and technology continues to evolve, and accessibility guidelines must evolve with them.
After three years of implementing and explaining WCAG 2.0, we have identified areas of the guidelines that could be improved or clarified. For a number of reasons, we are unable to participate formally in W3C processes, and we are unaware of any current plans for a WCAG 2.1 or a WCAG 3.0, so we present here some possible changes and improvements to WCAG 2.0, and items that we hope might help you better understand and implement optimal accessibility.
Success Criterion (SC) 1.1.1 (Non-text Content) allows an exception for CAPTCHA, as long as it is identified as being a CAPTCHA and “alternative forms of CAPTCHA using output modes for different types of sensory perception are provided.” If a site provides both a graphical and an audio CAPTCHA, it passes. This, however, continues to exclude users that are deaf-blind, not to mention the difficulties that all users have with CAPTCHAs.
CAPTCHA has failed. Automated processes can now bypass it faster and more accurately than actual users. WebAIM clients, even those in the highly secure financial services industry, are abandoning CAPTCHA. WCAG should do the same by removing it as an exception, or perhaps allowing graphical and audio CAPTCHA for Level A conformance but prohibiting all CAPTCHA at Level AA.
Several of WCAG 2.0′s media guidelines include “…except when the media is a media alternative for text and is clearly labeled as such.” This means that text alternatives are not required if the video is an alternative version of the main text content of the same page (for example, a web page with the text of a speech that also presents a video version of that speech). This, however, is often misunderstood to suggest that if a transcript is provided, then captions or audio descriptions are not required. This could perhaps be clarified to indicate that if the main content of the page provides all necessary content of the associated media, then no other requirements (captioning, transcript, etc.) are necessary.
“Alternative for time-based media” is a confusing term for a descriptive transcript – a text transcript of the audio or video that provides all necessary auditory content (such as identifying laughter or an off-screen explosion) and visual content (such as a list of items displayed in the video that are not presented via audio). We simply use “descriptive transcript” instead and have found is much more easily explained and understood. If a user reads the descriptive transcript, they will get all of the necessary content conveyed in the audio or video.
Synchronized captions are always required for audio/video content at Level A. Additionally, either audio descriptions (auditory presentation of visual content in the video) or a descriptive transcript is required for Level A conformance by Success Criterion (SC) 1.2.3. Either of these meets the needs of users with visual disabilities. If an author provides a descriptive transcript to satisfy SC 1.2.3, then audio descriptions are required in SC 1.2.5 at Level AA. However, if an author provides audio descriptions to satisfy SC 1.2.3, then a descriptive transcript is not required until SC 1.2.8 at Level AAA. This latter case would render the media inaccessible to deaf-blind users at Level AA, because both captions and audio descriptions are inaccessible to these (and many other) users.
This is all compounded by the fact that if the video does not require audio descriptions (meaning all necessary visual content is presented in the audio of the multimedia), then SC 1.2.3 and SC 1.2.5 are satisfied. This means that for such video (e.g., a talking head), the author is not required to provide a descriptive transcript unless they are seeking Level AAA conformance. In other words, if a page contains only audio, it requires a descriptive transcript at Level A. But if you add a talking head video or simply add the audio to some video content, it doesn’t require a descriptive transcript until Level AAA. This surely is a weakness in WCAG 2.0 that should be addressed.
Confusion and limitations of the current guidelines could be addressed by structuring the guidelines as follows based on the media’s characteristics:
This structuring would require audio descriptions or a transcript at Level A, but only if they are necessary for blind accessibility. At Level AA, all pre-recorded video would require transcripts. At Level AAA, video would require audio descriptions, if they are necessary due to visual-only content.
It is with great hesitation that I recommend moving audio descriptions to Level AAA (in WCAG 1.0, they were Level A). While they are the primary and preferred mechanism for providing multimedia accessibility to users with visual disabilities, one must balance their significant expense and difficultly to generate and the fact that transcripts provide equivalent content and are also accessible to a much broader audience (e.g., deaf-blind). Because a transcript will already have been generated in order to provide captioning, it seems more logical that the emphasis should be placed on providing a nearly universally accessible descriptive transcript, rather than on providing less usable and more burdensome audio descriptions.
White text on a white background is Level A conformant. No contrast requirements are present until SC 1.4.3 at Level AA. Adding a minimal contrast requirement (perhaps 2:1 and 3:1 for large text) at Level A would help address significant readability issues that could be found on Level A conformant sites.
Users with significant low vision rarely resize text in a browser. If a user requires text that is twice the default size, page zoom or a dedicated screen enlarger is and must be used. Designing modern web interfaces to support 200% text resizing is very difficult. This Level AA success criterion typically poses the most significant burden to our clients (often more so than captioning). We strongly recommend that the text resizing threshold be reduced to 150%, with perhaps a 200% threshold for Level AAA conformance.
It was pointed out to me that browser zoom is allowable to meet the requirements of this success criteria. This seems very contrary to the normative text which says that “text can be resized…” In short, it’s pretty much impossible to fail this success criteria for HTML content because all major browsers provide adequate zoom functionality. I believe this is a severe deficiency in WCAG 2.0. We know that many users prefer text sizing over page zooming. This adds credence to my recommendation above for a 150% true text resizing requirement.
Success criterion 1.4.5 requires that if the same visual presentation can be made using text alone, an image is not used to present that text. The possibility of highly stylizing text and page elements with CSS (especially CSS3) begs the question of how one defines “same visual presentation”. For example, a graphical button with rounded corners, a background gradient, and text drop-shadow could be recreated with text and CSS3, but it is not clear if this is required to meet this Level AA success criterion.
While using text is always optimal for accessibility (and for other reasons), Level AA conformance should only require that the graphical text be replaced with true text when readily-available font face styling will suffice. In other words, authors should not be required to implement significant text styling to duplicate the graphical text’s presentation. SC 1.4.9 (Level AAA) already prohibits all presentation of text within images.
A wide variety of “mechanisms” are available to allow users to bypass blocks of repeated content on web pages. This success criterion would be more meaningful and understandable if it required at least two possible mechanisms, such as:
WCAG 2.0 uses the phrase “can be programmatically determined” extensively. A wonderful article by Jason Kiss explains this term and its use in WCAG. This term refers to relationships that assistive technologies can make between content and/or markup. WCAG defines it to mean that technologies “can extract and present this information to users in different modalities”, whatever that means.
In most cases, when WCAG 2.0 requires that something “can be programmatically determined”, modern technology can actually do so. But not always.
As an example, if an ambiguous “click here” link is preceded by a descriptive heading, this is allowable at Level A by SC 2.4.4 because the meaning of the link “can be programmatically determined” based on the heading structure. The problem, however, is the word “can”. No modern assistive technology actually implements a method whereby the link is automatically made unambiguous because of this structural relationship. In other words “can be programmatically determined” does not mean “IS programmatically determined”.
This creates a situation where WCAG allows or requires something that does not actually result in any better accessibility. It also presents a situation whereby authors can’t know for sure if their content is actually conformant without knowing if assistive technology CAN do something. And which specific technologies or how many of them must do it before “can” means “can”? This is very akin to WCAG 1.0′s very confusing phrase “until user agents…”.
While supporting documentation attempts to clarify this, it remains a confusing aspect of page conformance. This could perhaps be addressed by more specific details at the success criteria or techniques level that reflect actual assistive technology capabilities, rather than simply suggesting that potential support is sufficient.
A lack of keyboard focus indicators for navigable page elements – SC 2.4.7 (Level AA) – renders a page nearly entirely inaccessible for the large population of sighted keyboard-only users. This is one of the most significant and pervasive accessibility issues currently on the web (see The Plague of Outline:0). There is no reason why this should not be a Level A requirement.
While the intentions are noble, SC 4.1.1 (Level A), which requires that significant coding validation errors be avoided, has little impact on end-user accessibility and is next to impossible to evaluate. The areas in which coding errors impact accessibility are already sufficiently covered by other success criteria (such as proper form labeling, frame titles, table headers, etc.). I can’t think of a single instance where a significant coding issue would impact assistive technology specifically. The parsing requirement should be removed or perhaps changed to require strict validation at Level AAA.
This is not intended to be a criticism of WCAG 2.0. The web is clearly much more accessible because of these guidelines. As future updates to WCAG are considered, and as authors implement these guidelines today, these recommendations might provide some clarity and guidance, with the hope of making the web more accessible for all users. If you have feedback on these recommendations, or have thoughts of your own on WCAG, please comment below.
Alexa 100 Accessibility Errors
Karl Groves recently published automated web accessibility test data for many of the Alexa Top 100 web sites. The results paint a rather stark picture of web accessibility. We agree with Karl’s suggestion that while automated testing is not a direct indicator of true accessibility issues, “poor performance in automated testing is strongly correlated with poor performance in manual testing.” Jennison commented that not all errors are created equally, and this is very true, yet the preponderance of automated errors is clearly indicative of serious issues.
The table below outlines errors for the home pages of the Alexa Top 100 US sites (excluding porn, content farm, and advertising sites). The WAVE toolbar was used to calculate errors. Because the WAVE toolbar evaluates content after JavaScript is processed, and because WAVE errors almost universally indicate a significant accessibility issue, the number of errors is generally a good indicator of true end user accessibility issues.
Care should be taken in interpreting these results. These data should not be used to cast a sweeping judgement on a site. Home pages are often dissimilar to content pages, though these data generally correlate to Karl’s more extensive analysis. Regardless, the fact that an average of 25 errors per home page are present, and that only 4 of the 100 home pages had 0 errors is rather telling. There is much that still needs to be done to improve web accessibility.
WebAIM is an initiative of:
