Methods of Indicating the Purpose of a Link | SSB BART Group. Methods of indicating the purpose of a link Overview The different methods of indicating a link’s purpose are often misunderstood and incorrectly implemented. The Web Content Accessibility Guidelines (WCAG) explicitly require that link text accurately reflects the target and purpose of the link. While current Section 508 standards do not explicitly state this — many Federal Agencies in the US require similar practices under Section 1194.31 Functional Performance Criteria. The harmonization of Section 508 as indicated in the US Access Board’s last Advanced Notice of Proposed Rulemaking (ANRPM) also indicates that link purpose will be explicitly required when Section 508 is refreshed. A number of techniques exist that can be used by developers to meet the WCAG success criteria. Implementation One of the easiest ways to clarify a links purpose is to directly change the on-screen text of the link.
The Title attribute CSS based Off-screen Text Other considerations Frameworks for Categorization. Is PDF accessible in Australia? More than two years ago I wrote about WCAG 2.0 and Accessibility Supported, and my fear that, “the concept of ‘accessibility supported’ is not fully understood”. I believe that this “could put at risk the whole move to improve the accessibility of the web.” I am concerned that mixed-messages relating to the status of PDF as a “web content technology” is still causing problems within Australia at least. I have presented many workshops about web accessibility and WCAG 2 compliance and the issue of “accessibility supported” is at the heart of some of the most common questions I get asked. Specifically, many developers want to know if they are still required to provide an accessible alternative for the PDF and/or JavaScript they include in a site.
When answering questions like this I stress, of course, the need to ensure all content is as accessible as possible and the five Conformance Requirements for WCAG 2.0. Changing attitudes We need clarity. Tables that make sense. While catching up on some online reading this morning, I came across an article in the Washington Post titled "College Majors and Their Income Potential". I was curious how my brother, a recent grad with degrees in Italian and Political Science, would stack up. Here is the table that was included with the article: I started to read the table. It looks nice: visually clean, no unnecessary clutter. When I first dove into the detail, I thought it might be ordered by increasing Unemployment Rate: 7.0...7.7...8.2...5.4?
Nope. Ok, perhaps it's ordered by increasing Earnings: $32K...$32K...$46K...$33K? The table is not ordered by anything meaningful, as far as I can see. The lesson? In general, think about whether there's an intrinsic order to the segments that you need to leverage. Bottom line: make your table make sense. Accessibility tools, web developer tools, wizards and markup generators. Accessibility Tools Updated Accessible Table Builder - Create an accessible table using scope, header and id attributes using a wizard to guide you through the process.
Updated Quick Form Builder. A complete re-write/re-think of the old Accessible Form Builder tool. Give it a try! Show additional archived content (which may no longer be up-to-date). Accessible Form Builder - Quickly create a form with CSS or table layout, including all label elements simply by typing a list of fields that you need. General Developer Tools Markup Maker - Takes a simple list of page ids that you enter and converts it to a valid XHTML document. Take the Accessibility Challenge: Make Your Next Blog Post Accessible in 75 Seconds | Blog Accessibility. “I want to do the right thing and make my blog accessible to people with disabilities, but I have so much to do. I just don’t have the time.” Nonsense! Start with the area you have the most control over: the piece that you write regularly – the post. Consider the ingredients of a basic post: an image, an acronym or two, a few hyperlinks, maybe a couple of headings and even a list. I challenge you to make those ingredients accessible in 75 seconds or less.
Are you up for the challenge? The following instructions are for WordPress 3.3. Adding an alternate text to an image After uploading the image, delete the file name from the Title field (that is utterly useless!) Time: 30 seconds Making hyperlinks meaningful When writing a text hyperlink – text that is clickable – word it in such a way that the text makes sense when read alone. For example, rather than writing: I wrote about hyperlinks here. Consider: I cautioned against using consecutive one-worded links. Time: 20 seconds Time: 0 seconds. Programmatically Determined.
The phrase "programmatically determined" features prominently in six of the 61 WCAG 2.0 Success Criteria. It's a bit of a mouthful, for sure, and perhaps a little daunting to those getting into accessibility and WCAG for the first time, but it's really not that complicated. In fact, you may already have a handle on it, even if you're not familiar with the phrase itself. Whatever the case, I think "programmatically determined" is a very useful concept for explaining, particularly to web developers, something about WCAG, what web accessibility means and why the proper use of HTML is so important.
It's in the HTML Behind all your typical web page content is, of course, the HTML markup. Most people never see a web page's HTML, but the browser used to access a web page relies on it to understand the page's content. Providing this information about content structure and relationships is a fundamental part of what HTML was designed to do and of how it is meant to be used in the first place. Web accessibility myths 2011 – a call for accessibility advocates to be more business-minded. It’s the time of year when web accessibility advocates tend to produce accessibility myths blogs… As nothing stays still on the web, and many of these blogs are rather old (other than Ian Pouncey’s great blog earlier this year), it’s important that our understanding of accessibility myths moves on too… So, for Christmas 2011, and to hook-in with the user-research blogs in my series on implementing BS8878, here’s Part One of some accessibility myths I’d like to expose to clear out the cobwebs before 2012, based mostly on my experience and user-research from my time at the BBC.
And, yes, I’m going to be provocative. This isn’t for cheap effect, but aims to challenge some of the accepted assumptions many accessibility advocates hold which I believe are really not serving us, or the disabled and elderly people we are trying to help, well at all. New: get it in pictures… Checking Our Footing: 16 Modern Accessibility Myths Debunked from Jonathan Hassell 1. No, they don’t. 2. 3. 4. So which is it? Ian Pouncey » Blog Archive » Web accessibility myths. Posted: January 23rd, 2010 | Filed under: Accessibility, Web Development | Tags: accessibility, web development | 22 Comments » There is a lot of good advice for the discerning web developer to find on the web on how to make a website accessible, unfortunately there is also plenty of bad or outdated advice out there as well.
Here are a few of the myths of accessibility that you may hear. Validation equals accessibility Good markup is the foundation of a usable, accessible and robust website. Testing that the HTML (and CSS) that you write passes a validation test can be very useful, and in general validity is something to strive for. As my colleague (and true accessibility genius) Benjamin Hawkes-Lewis puts it, valid code is a contract between you and the browser vendors – you write valid code, they will render it correctly (in theory!). But this is not the same as accessibility, validators do not check that alt attributes are relevant, or that link text is useful. In conclusion… 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.
We received 1245 valid responses to this survey (1049 English, 101 Spanish, 91 French, and 4 Portuguese responses). This was a follow-up survey to the original WebAIM Screen Reader User Survey of January 2009 and follow-up surveys in October 2009. 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 Screen Readers Commonly Used. Web Accessibility In Mind. Document Solutions - You Reap What You Sow: The Australian Government's Report on PDF Accessibility.