Category: w3c

Companies’ Accessibility Twitter Accounts and More

Here are some large companies’ accessibility Twitter accounts, and other important related links. Follow for great information. Most of the descriptions are taken from the Twitter bio.

  • @PayPalinclusive – An official feed from the PayPal Accessibility Team and related initiatives. For account-related issues, contact @AskPayPal. San Jose, California.
  • @IBMaccess – Official IBM Accessibility Twitter account. Managed by @timjpowers & @Mac690 and follows the IBM Social Computing Guidelines. San Jose, CA · ibm.com/able
  • @GoogleAccess – The official Twitter account for Google’s accessibility team. California, USA · google.com/accessibility/
  • @FBaccess – The official Twitter account for the Facebook accessibility team. Please report specific accessibility issues at the Facebook accessibility help center.
  • @NokiaAccess – Making mobile devices accessible for all. Dallas, Texas · nokiaaccessibility.com
  • @w3c_wai – not really a “company” but the owner of WCAG. Nuff said.
  • @STCaccess – [Society for Technical Communication] Tweets from the SIG (Karen and Cyn) about accessibility issues for technical communicators, spiced with dashes of usability and other goodies. stc-access.org
  • @BBCOuch – blog and radio talk show on the BBC with a focus on disabled people and diverse stories. London · bbc.co.uk/ouch/
  • @YahooAccess – closed, very sad. Hopefully will come back one day. Also, the Yahoo accessibility blog appears to be no longer maintained.

And of course, follow me on Twitter at @WebAxe and also on my Facebook.

More

Overwhelmed? Stick To Basics

A few people at the CSUN conference last week commented on the overbearing WCAG 2.0 specs. Many folks agree that WCAG is extremely large and difficult to read (not unlike the HTML5 spec). And especially for accessibility newbies, WCAG can be a difficult place to start.

In a session at CSUN, even the W3C WAI members said that beginners should not read the spec but start with other docs such as How To Meet WCAG2 which pulls the Understanding and Techniques together. The WAI is also working on a “Easy Checks” documents. Here’s a sneak peak to the draft titled Easy Checks – A First Review of Web Accessibility [link updated].

If you are feeling overwhelmed or confused about web accessibility, my advice is this: stick to the basics.

For design, this means not re-inventing HTML elements and behaviors. Particularly form elements, such as re-rendering a select dropdown for the sake of aesthetics. There’s also the horrible trend to make labels appear and function like placeholders.

For development, this means the proper foundational techniques. Namely, the four layers of web development:

  • Semantic HTML for content.
  • CSS for presentation.
  • JS to enhance behavior.
  • ARIA to fill any accessibility gaps.

This fun diagram on Flickr helps illustrate this point.

Using the four layers approach encourages the following good practices:

  • Separating content from presentation from behavior.
  • Maintaining code in external files.
  • Adding ARIA only when needed.

If these practices are implemented in a website, it’s well on its way to being accessible.

AAP Provides Longdesc Feedback to W3C

There’s a debate over whether or not the longdesc attribute should be made obsolete in HTML5. I wrote a bit about it a few months ago in the article Longdesc & Other Long Image Description Solutions.

Recently the Association of American Publishers (AAP) submitted feedback on longdesc to the W3C HTML 5 Working Group. It’s very well written and thought it should be shared. I obtained permission to publish the response (thanks Suzanne and Ed). Here is the main part of it:

Use of structured text as a text alternative for an image is supported in HTML through the longdesc attribute. Though there are other options for presenting structured-text, the longdesc attribute provides following benefits:

For User Experience

  • The longdesc attribute is a dedicated mechanism for just this purpose, and it always works in the same way:
    • Students and instructors will find the same user interface throughout all materials, so they will not need to learn new interfaces product-to-product, which takes time and attention away from the learning content.
    • The longdesc attribute can be revealed programmatically through browser extensions, providing access for users who do not use screen readers. Many users benefit from text alternatives, especially users with low vision.
    • The longdesc attribute does not impact the visual design. So, authors do not have to worry about how the text might impact the visual user experience. Authors can, therefore, focus on the experience of students and instructors with visual impairment while they write text alternatives. This focus on the primary audience helps authors create text that is well-suited for its purpose.

For Production Processes and Quality Assurance:

  • The longdesc attribute is easy to code. There is no need for custom scripting.
  • The longdesc attribute works with assistive technology today. If the longdesc attribute continues to be supported, content that works well for users today can be used in future products without editing.
  • The longdesc attribute can be programmatically recognized and tracked, allowing publishers to locate existing long descriptions and to test for the presence of long descriptions.

We are using longdesc increasingly in our products. Unless a different mechanism is created that meets all these requirements, we urge the W3C to keep the longdesc attribute in HTML specifications moving forward.

We do acknowledge that user agent support for the longdesc attribute should be improved. In particular, users who have low vision or who find image descriptions helpful for any reason should be able to set their user agent to reveal the descriptions. The HTML 5 specification should clarify that user agents should provide this functionality in addition to passing information to assistive technologies. In this case, publisher documentation for products with numerous longdesc attributes might include tips about use of these user agent settings.

Evaluating Other Solutions

We discuss the aria-describedby attribute following to illustrate that solutions that at first seem to duplicate the qualities of the longdesc attribute may not actually be as useful when implemented.

The aria-describedby attribute takes the unique indentifier (“ID”) of another object on the same page as its value. In other words, it points to another object (e.g. a paragraph or a link) on the page. This attribute could become an effective way for developers to indicate that the information provided by an image is actually redundant with other information on the page.

Screen reader developers might implement this attribute so that it is silent in screen readers when used on an image by default. They might also allow those who want additional information to set their screen reader to announce aria-describedby and to provide a way to jump to the object indicated by the attribute. An instructor, for example, might choose this setting to be aware of what sighted students will be experiencing.

But, the aria-describedby attribute falls short as a mechanism to link to a separate page of structured text. The aria-describedby attribute could point to a link on the same page as the image, but:

  • Hiding the link visually would require custom CSS or scripting. The mechanism for hiding the link would therefore differ product-to-product, making browser extensions or features to show the links more complex to code and less reliable for users.
  • The link would have to be present on the page for screen reader users, creating redundancy for those users.
  • Since the aria-describedby attribute points to a link or to other content on the same page, its structure implies a two-step process to reach the text alternative. Compared with longdesc, the two step process is more tedious:
    • The user moves to the object that aria-describedby references.
    • If the object is or contains a link or a button, the user interacts with that object to move to the text alternative.

If the issues above are resolved and aria-describedby is used as a way to access descriptions that are otherwise hidden from all users (including screen reader users), another problem emerges. In that case, aria-describedby cannot be silent by default in screen readers when used on images, compromising its use to illustrate that the content of an image is already available on the page. Developers may not realize the distracting and frustratingly circular user experience that this would cause and might use aria-describedby to point to, for example, a paragraph just above the image. Users would then likely follow the aria-describedby announcement, expecting to find additional content, but they would arrive, instead, at a paragraph that they have likely just read.

We urge the W3C HTML Working Group to write out the expected implementation and user experience details of any proposed replacements for the longdesc attribute to be sure that they will be at least as effective as the longdesc attribute in practice.

Involving Users Early in Web Projects

The W3C article Involving Users in Web Projects for Better, Easier Accessibility gives excellent guidelines for developing accessibility in a web project. The article states:

Involving people with disabilities from the beginning of a project helps you better understand accessibility issues and implement more effective accessibility solutions.

In my experience, this couldn’t be more true. Nothing is much worse than having to retro-fit an existing web site or web application for web accessibility, or having to explain what assistive technology is to the author of the specifications document. You must plan from the start, and implement at the end (an old Hijax saying). When the different teams on a project understand accessibility, including the developers, it certainly makes the project run much more smoothly and efficiently.

The article discusses the following items in detail:

  • How Involving Users Early Helps
  • How to Involve Users throughout Your Project
  • Getting a Range of Users
  • Working with Users
  • Combine User Involvement with Standards

These techniques can be applied to more than web sites; also assistive technologies, media players, authoring tools, policies, and technical specifications.

For more, here’s the W3C blog discussing this article: Discover new ways of thinking about accessibility.

Web Accessibility Day

Web Accessibility Day is Tuesday, September 22 in Baltimore, Maryland, U.S.A. It’s a a one-day event teaching how to create web accessible content including PDFs and graphics, and how to use evaluation tools.

The keynote speaker is Shawn Lawton Henry, Outreach Coordinator for the W3C Web Accessibility Initiative (WAI). Exhibitors include: Oracle, Knowbility, Nuance Communications, and Browse Aloud.

Web Accessibility Day is presented by The National Federation of the Blind and the Maryland Technology Assistance Program. Support for the Web Accessibility Training Day is provided by the State of Maryland Deparment of Information Technology.