Categories
google screenreader visual

Response to Accessibility in Google Docs

Read Write Web recently published the article Google Announces Sweeping Accessibility Improvements for Visually Challenged Users. On one hand, this is great news. But on the other hand, Google’s accessibility efforts have been inconsistent, and mostly within their own technologies; as we’ll discover below, not implemented for universal use.

The Google Docs updates have been tested by a screen reader user, Kevin Chao. With permission, the following is taken (and slightly edited) from his web post Google announced and took the wraps off what’s been dubbed “enhanced Accessibility in Google Docs”.

Google announced and took the wraps off what’s been dubbed “enhanced accessibility in Google Docs”

Applaud, Thank, and Appreciate

I certainly applaud, appreciate, and praise Google in their accessibility efforts, but there seems to be this level of accessibility, which includes efficiency, effectiveness, and equal access that Google is far from with all attempts, which Docs is no exception.

Dumbed Down Accesssibility limited UI/Look

Visiting Docs.Google.Com using Firefox and NVDA, either classic or new Look/UI, latter is much worse from an accessibility point, but all is relative, including “enhanced accessibility”. Google is always in in a race with itself, changing elements, such as looks/UI. Often there are different views to pick from, and it’s often the one that is “basic” or “classic” that is more accessible, which leaves screen readers with a dumb-downed experience than an equal experience Compared to the full “standard” or “new” UI/look that everyone else who does not need to use a screen has the luxury of using. There should not be more than one view, if there has to be an experimental/enhanced view, it should be accessible, and it’s very degrading that Google by only putting accessibility resources into the dumbed UI/Look implies that all blind screen reader users are unable to perceive, understand, and work with advance, complex, and rich UI/Looks.

Now, let’s move onto the main focus, which is the enhanced Accessibility in Google docs.

Using Firefox, NVDA, and looking at Docs.Google.com in classic view.

Main UI/Look
  • Navigating by form fields or line will reveal lots of unlabeled Controls, such as “button”, clickable, expanded, checkboxes, and clickable list. It’s bad enough from a user interface, experience, and accessibility standpoint that all these controls do not have proper labels, making them accessible, but there’s more.
  • Instructions indicate to get started, activate create new or upload button, but these are identified as clickable, which do not do anything when pressing ENTER. However, with enough attempts of everything under the sun such as NVDA+CTRL+SPACE, SPACE, mouse click, etc.; it will be possible to activate these buttons. It should not be this difficult, frustrating, and require all these work-around to activate buttons (no, no, they are not buttons, but clickable).
  • When navigating to the expand button, pressing ENTER, NVDA is silent. The new status, which is collapsed, is not conveyed from Docs via ARIA or any accessibility event. In addition, arrowing down does not show any additional content. ARIA Live-regions should be used to alert user of updated dynamic content.
  • Navigating to unlabeled button, pressing ENTER, reviewing contents on screen does not show that anything changed.
  • Lots of items are identified as menus and submenus, which when activated do not work as ARIA jQuery menus, but instead do not do anything, cannot track focus/read, and/or it’s not possible to exit menu/submenu.
  • Effective and efficient navigation is lacking greatly, which could Be improved by use of ARIA Landmarks and headings.
Creating/Editing Docs
  • Browse/upload process does not work by simply using arrows/TAB and ENTER/SPACE, but requires the same level of fighting, frustration, and work-around that was required to get into the upload page.
  • Creating a new doc/opening an uploaded one will open it in a new Tab, which is identified with: document title, app, JavaScript, file type, and editable”. While all this is great, arrowing in document reads absolutely nothing and same goes for tabbing around.

Conclusion

Google has optimized Google Chrome, ChromeVox, and Docs to work very well together. This locked-in and non-universal design towards accessibility should be avoided at all possible cause, which results in not as many people using it due to the need to use a different environment for particular task. One of the many benefits to a cloud solution, such as Docs is the anywhere access on anything, which ranges from desktops to mobiles, which Docs accessibility is far from.

Please, Google, there really needs to be real accessibility present, which includes effectiveness, efficiency, and equal level of access. No more of this Google accessibility, which is half-baked at best.

Categories
cms drupal wordpress

About CMS Accessibility

This article was written for Web Axe by our friend, John Siebert, a Tampa Web Designer who has an interest in creating accessible web sites.

Content management systems (CMS) are a good way to go for both personal and business use. An open source CMS can get a website up efficiently, but is it accessible? With about 25% of internet users needing accessibility, it is very encouraging to keep your site web accessible. This is for every “human user” disabled and non-disabled no matter what browsing technology they are using. CMS platforms can definitely help you with that. But which one is the most accessible friendly? We will look into WordPress, Drupal, Joomla, and Posterous and compare the level of web accessibility.

All users have equal access to information and functionality. It is the developer’s responsibility to correctly design and develop a site that everyone can view and understand. What effects accessibility includes layout, markup, images and media, and JavaScript. A good CMS platform can make sure that these issues are compliant.

WordPress

WordPress states that it is web accessibility compliant. Unfortunately if developers tweak or create templates, it is up to the developer how well or little they configure accessibly into the site. There are plenty of accessibility plugins that a developer can implement into their WordPress site.

Here is a very helpful link full of WordPress accessibility plugins. WordPress also provides plenty of information and guidelines for creators that cover all basic HTML topics. Also check out the comments in the Web Axe blog on accessible WordPress themes.

Drupal

Drupal has plenty of helpful links for tips and topics to input accessibility into their platform. A helpful Drupal tutorial goes over:

  • What are the common accessibility barriers that my website needs to overcome, and how?
  • What tools help me manage the accessibility of contributed content that is beyond my control?
  • What Drupal modules and 3rd party accessibility tools will help?

You may want to check out the Web Axe podcast on the Drupal 7 and accessibility from last October. And here are a few more links for Drupal accessibility:

Posterous

Posterous does not cover as much accessibility information as other CMS platforms. Which leads me to believe that Posertous would not have much support for developers using their platform. We think it’s time Posterous stepped up to the plate on this issue and have sent them an e-mail with our concerns.

Joomla

Joomla has their own accessibility statement that shares their promises of fulfilling a true web accessible environment. However, they state that it is up to the designers and template designers to follow rules and regulations. They also state that they understand that the Joomla site itself does not comply with many WCAG/508 requirements.

Conclusion

When choosing a CMS platform, find one that has the most web accessibility support. The best would be WordPress and Drupal out of the four compared. By using a CMS platform you will have more support to maintain a web accessible site. Most of the accessibility changes can be fixed once and to the entire site through these platforms, saving time and money.

The best way to understand accessibility is to get to know a user that benefits from the accessibility you put into code. Once you understand the reason why accessibility is important for your site, you can then comprehend the reason for a CMS platform like WordPress or Drupal as the base of your site.

If you have any feedback about CMS and accessibility, especially Posterous and Joomla, please leave a comment.

Categories
event law podcast twitter

Podcast #92: Frustrated

Dennis vents about frustrations around web accessibility and revisit the “game plan”. He and Ross also discuss some great recent articles and review several upcoming web accessibility events.

Download Web Axe Episode 92 (Frustrated)

[Transcript of podcast 92]

Sponsor: Help make a difference and join Project:Possibility: a nonprofit organization dedicated to creating open source software that benefits persons with disabilities. Our SS12 Code for a Cause competition is an opportunity for students to learn about accessibility and make a difference by developing innovative projects for persons with disabilities, as well as the chance to work with industry professionals.

Goings On

Ross’ book update.

California court rules for JetBlue:

Old Twitter gone for good; New Twitter not accessible.

  • The official word about the final rollout of New Twitter.
  • Forced to use New Twitter & unable to use it? Try the robust and web-accessible Easy Chirp (@EasyChirp). On iPhone, try TweetList.

Frustrated!

Unfortunately, after 20 years since the World Wide Web opened to the public, I’d have to say that accessibility is worse than ever.

Related links:

Articles

Web Camp/Unconference Reminders

Accessibility Camp Montreal
Friday, August 26, 2011
Montreal, Canada
Twitter: @A11yMTL

Boston Accessibility Unconference
Saturday, September 17, 10am to 5pm EST
Twitter: @a11ybos

Accessibility Camp Toronto
Saturday, September 24
Toronto, Canada (OCAD University)
Twitter: @A11yCampTO Email: a11ycampto at gmail dot com

Web Accessibility London Unconference
Wednesday, 21 September 2011, 10am to 4pm
London, UK (City University London)

Accessibility Camp DC
Saturday, October 22
MLK Library in Washington, DC
Twitter: @AccessCampDC

Categories
"assistive technology" video youtube

Accessibility Videos

Here’s a great list of videos and YouTube channels about web accessibility, assistive technology, and more. And from some excellent sources!

Categories
html5 longdesc w3c

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.