Category: law

Categories
analysis gov law

Critique – New Section 508 Web Site

Below are suggestions for improving the web accessibility of the new United States government Section 508 web site. Well, from analyzing the home page at least. This is basic stuff and I’m very disappointed that the site leaves so much to be desired. The site, which is U.S. government law with rules for web accessibility, should itself be an example of an accessible web site. And with the recent ADA anniversary, this was a great opportunity to move forward in the field of web accessibility. But instead, unfortunately, this was a failed attempt. The U.S. government has a lot of work to do.

Core Issues

  • No headings! Not one. Need headings in markup, period. There are many headings indicated visually, but inappropriately coded such as using strong or div tags.
  • Labels for text inputs are incorrect; there’s a label tag, but no text label! See the search text and email address for news signup.
  • Alternative text for many images need improvement such as removing “Graphic for”. Better yet, do not use a graphic when it’s not needed; text is fine in the following two cases. (Losing the inline style would also be good.)
    • Example 1:
      Graphic for how do I get my 508 questions answered
    • Example 2:
      Graphic for An Official Website of the United States Government
  • No keyboard focus to match mouse hover effect. In addition, a hover & focus could be added in several places to make it more usable, such as the first-level items in the left/main navigation menu.
  • The “AddThis” social media feature requires JavaScript and in either case is not keyboard accessible.
  • No ARIA implemented, not even landmark roles to help with navigation.
  • Links such as “read more >>” have no context; not unique. Also recommend removing the “>” character (better to use CSS for these types of markers/symbols).
  • Text links are not clear. The underlines are removed and dark blue not distinct enough from black text.
  • Poor progressive enhancement. With JavaScript off, the menu options do not fully display and the content of the slider feature is not displayed.
  • Redundant title attributes must go! I’m so tired of seeing this. It’s not useful but on the contrary gets in the way; and it creates code bloat. Example: Link Policy
  • The placeholder email content is confusing. The example is not even a valid email address (missing the top-level domain). The feature can be done with unobtrusive JavaScript and even use the label text, if it existed.

Other Issues

  • Horizontal scrollbars in 1024 resolution. Need better resizing/width design.
  • Lots of CSS in header (and inline); much better to use external file.
  • The attribute language=”JavaScript” not needed in XHTML.
  • Why display the date? Just adds to cluttered screen.
  • Print button not needed. Just adds to cluttered screen. Requires JavaScript.
  • Conditional comment for IE6 CSS should be in head, not body.
  • Text resizing tool not needed; let the browser do this! And clutters screen.
  • Some navigation items use lists while others do not.
  • Image need better optimization/compression. One image alone in the slider feature is over 150k and can easily be compressed to 35k.
  • 67 XHTML validation errors.
Categories
conference javascript law links roundup webaim

Link Roundup – June 2010

Categories
alt flash image law

Walmart’s Poor Alt Text and Use of Flash

Yesterday, Steve Faulkner of The Paciello Group wrote a tweet quoting an alt attribute on the Walmart.com home page. My first reaction was disbelief, frustration, and outrage.

I replied to the tweet, then found the following code (line 2421) which Steve was referencing:

The Walmart.com site includes Flash technology. To avoid interruption of software designed to aid visually-impaired people, please turn off your Flash player.

The message was designed for screen reader users. But just this one line of code is so wrong on so many levels including the following.

  1. A spacer GIF? What is this, 1998? This is a badly outdated and poor practice.
  2. Alt text is too long; I suggest under 15 words. Or, include the text as part of the main page or use some kind of “D” link.
  3. This message was meant to be vital to the user (particularly if blind), and thus should not be stuffed in an ALT attribute.
  4. Many people with visual impairments may not be blind, but have “low vision”, and thus may not use a screen reader. These individuals could use a screen magnifier or simply enlarge text with their browser.
  5. Law: Walmart is a very large corporation providing sale of goods nationally; this means that they are a great “Target” for a lawsuit, excuse the pun! (If you don’t get the joke, read about the NFB vs. Target lawsuit.)
  6. The use of Flash in itself is highly debatable. One can write a book about this point, but basically, Flash requires a proprietary plug-in, usually not developed with accessibility, and is not supported on many modern user agents such as the iPhone/iPad (not to mention many others including text-only browsers).
  7. How does one turn off his Flash player, anyway?

Solutions

Immediate: Provide HTML alternative to content.

Better: Use accessible Flash and provide an HTML alternative to content.

Best: Use HTML only for content. Implement with web standards, progressive enhancement, and DOM scripting, to create the same visual effect as the original Flash. This will not only make your content accessible, but will also make the site lighter and faster and is also good for SEO.

Categories
color expert keyboard law

Colorblind, Law, and Lightboxes

Color Sensitive

I usually shy away from About.com, but I recently came across a piece worth mentioning. In the article Are Your Web Pages Color Sensitive? from the HTML/Web Design section, Jennifer Kyrnin provides some good information and techniques for web development with color blindness in mind. Here are some good tips from Jennifer:

  • Don’t use only color to indicate something specific on your page.
  • Desaturate your images to see if they still have impact.
  • Avoid placing red and green together.
  • If you can, find a color blind friend or relative to look at your site.

Did you know that color blindness is an issue with 8 to 12% of males of European origin?

Law Needed

In his blog Yes, we need accessibility laws, Eric Eggert gives an argument for why we need better laws for web accessibility. He states that a good accessibility law should do:

  • Create awareness.
  • Do not create a climate of fear.
  • Create mediations.
  • Reference international standard.
  • Be inclusive.

Lightboxes

In the article Lightboxes and keyboard accessibility from 456 Berea Street, Roger Johansson describes how a lightbox should function with a keyboard. He states:

  • Let me use the left and right arrow keys to step through images in a slideshow.
  • When I press Esc, close the lightbox.
  • Do one of the following:
    • Either add focusable elements (links or buttons) for close/next/previous, put keyboard focus on the first focusable object in the lightbox, make sure I can’t tab to something behind the lightbox, and make it visually obvious which object has keyboard focus.
    • or close the lightbox when I press Tab.
  • When the lightbox closes, return keyboard focus to where it was when I opened it.

In addition, Roger cites the following two articles:

Categories
law survey

SurveyMonkey – web accessible or not? NOT!

SurveyMonkey claims Section 508 compliance and web accessiblity, but that is false.

Accessibility Statement? No, but info about accessibility in Help Center.

Tweet from Jared Smith
Survey Monkey’s problem is labeling method. Labels repeat A LOT (up to 6 times!). Turns label of “1” into “one hundred eleven” or “eleven”.

Tweet from mr_beeps
I had assumed the accessibility statement was referring to *future* releases of survey monkey, not the current one!

Jared:
Despite what Survey Monkey claims, their forms are not very
accessible. They are technically accessible, but not very useful. I’d
maybe consider replacing the radio button options with select menus.
They just seem to me much easier for screen reader users in Survey
Monkey. The problem is that the label for each element is usually read
multiple times (sometime 6 times) because of the way it’s coded. Radio
buttons don’t use fieldset/legend, but the label for each item is
coded multiple ways. The grid of answers were particularly difficult
with JAWS repeating the label for each item over and over and over
again. Putting each in a select menu (“How would you rate Accessible
Twitter’s speed”) would be better.

And this actually causes other significant items. On the “How many
times” question, the labels are repeated multiple times, but JAWS
jumbles them together. The radio button labeled “1” is there two
times, JAWS actually reads “one hundred eleven” the first time it
reads it and “eleven” when you cycle back through the radio buttons.
“2-5” is read as “two dash fifty two, two dash fifty two, dash five”.
Spelling out the numbers would help… a bit, though it would then
read “two dash five two”.

SurveyGizmo
SurveyGizmo’s accessibility statement