Category: navigation

The Web Site Accessibility Page

The accessibility page of the State of California web site lists many claims on what makes their web site accessible. Frankly, I’m pretty embarrassed for this state is which I live; nearly all of the bulleted items have major web accessibility mistakes and flaws. Let’s take a look. (All of the assessments were made from referencing only the one accessibility page.)

Clean, Simple and Consistent
This is true. Although it’s consistently inaccessible, as we’ll see.
“Skip To:” Menu
Skip nav is good, but it’s not visually displayed, not even when tabbed upon. This is a major issue for sighted keyboard users. Also, the skip link lands the user before the breadcrumbs; it should go past the breadcrumbs since the object is to pass over all the navigation to the main content.
The Navigation
The main menu requires a mouse to access the second level of items, therefore, it’s not keyboard accessible. What’s worse is that the second level links are not listed on the main page of parent menu item! In other words, there’s no fallback.
Breadcrumb Navigation
Breadcrumbs are a good idea, but first of all, they require JavaScript [on this site’s implementation which is unnecessary; a server-side solution is ideal]. And, there is no semantic markup or a heading denoting what this section is. Also, it’s better practice to markup the breadcrumb links in an unordered list.
Images With Alternative Text
Wow, I didn’t know that alt text is “visible when the mouse is placed over the image”! LOL, that’s just silly IE. (It’s the title attribute which is rendered as a tooltip in most browsers.) Also, say no to alt=”bullet”, yuck!
Relative Font Sizing
This doesn’t work when the text is a graphic! A graphic doesn’t increase when text size increased. See “Popular Pages”. Note that graphic text will increase in size with page zoom, but then may be very pixelated and unreadable.
Style Sheets
What? The second paragraph is instructing the user to install a developer toolbar!
Fluid Sizing Display
Says “viewed best at a minimum of 800 x 600 pixels” but the web page doesn’t fit in that screen resolution! There’s a nasty horizontal scrollbar. So I took a better look and there is no fluid sizing. The CSS is clearly static: width:972px;
Accessible Via Mouse or Keyboard
Uh, no, see reasons above.
Access Keys
Implementing access keys is an outdated practice and get in the way of assistive technology. But the site has implemented only 1 anyway. Just silly. Draw your own conclusions here.
No Sound, No Images, No Problem
Lies I tell you!
Improved Search Engine
This is more of a usability issue.

Although there’s clearly a lot of effect here, it’s almost worse off than no effort at all. Sticking with semantic markup and unobtrusive JavaScript in itself may have been a better start.

Screen readers and navigation

i navigate by headings when reading a long technical document or news items and essays that are large

i try to navigate by edit box when i can (using edit box navigation, i get the “donate” edit box before the Username edit box on the AccessibleTwitter sign-in/home page, which is a bit unexpected from a user’s point-of-regard)

on pages with multiple forms, since ARIA and the Role Module lack a “form” landmark (the closest thing is “search” – i logged a bug against ARIA 1.0 and the Role Module requesting “form” as a predefined role), i usually use either an AT-generated or a UA-generated list of form fields which is navigatable not just through use of the UpArrow and DownArrow keys, but by first letter of the labelling text

yes, accesskey is problematic with IE as there is no way to cascade ALT+Key so that a user can use the accesskey without conflicting with the UA’s chrome — but FireFox overcame this by using ALT+SHIFT+Key on the windows platform, and Opera has the most customizable accesskey options available anywhere…

my point of view on accesskey is that it does work under the right circumstances, and in those circumstances it is a DEFINITE time and energy saver when one can simply jump-to a particular form and/or form field using an accesskey — to me, the benefits outweigh the drawbacks, but that is simply my opinion, which is both philosophical and practical — or at least so i like to tell myself…

FYI, i’ve been working on accesskey replacement strategies:

1. general HTML A11y Task Force Access (Key) Replacement Wiki Page:

2. Accesskey Replacement Requirements (approved by PFWG years ago):

3. a plan to port the XHTML Access Module to a generic Access Element
to address navigation not only in structured, but in stacked, markup
langauages as well:

4. rob burns’ (robburns1 on twitter) Command & Event and Keyboard
Focus Module:

worst offenders are forms inside tables? one has to use table mode to get oriented and check labelling, then switch to forms mode in order to interact with the form fields — aria will definitely help this, but what would help FAR more is if content developers actually abided by the newish verbiage in the HTML5 draft that explicitly bans the use of TABLE for layout or stylistic purposes

Podcast #37: Code Considerations for Web Accessibility

Dennis and Ross discuss various techniques on coding for web accessibility (in follow up to Podcast #34: Design Considerations for Web Accessibility). Topics include:

Download Web Axe Episode 37 (Code Considerations for Accessibility)



Podcast #34: Design Considerations for Accessibility

Considerations for designing an accessible web site, including discussion on web site conventions, navigation, color, text, and layout.

Download Web Axe Episode 34 (Design Considerations for Accessibility)

[Transcript for Web Axe 34]

Stick to Conventions

  • Search upper right
  • Global navigation across top
  • Sub navigation on sides
  • Icons

Navigation Considerations

  • Skip navigation
  • Indicate visited pages, current page
  • Use breadcrumbs where possible

Color Considerations

  • Ensure enough color contrast
  • Light on dark, or dark on light?
  • If you change the color of an anchor state, change them all
  • Never use color to convey information

Layout Considerations

  • If you have a low vision/large text style sheet, convert layout to one column
  • Pay attention to if it is obvious you can scroll downward or not
  • If Article is broken up between several pages, provide a link to a single page with the whole article for easy printing
  • Try and design for 760px minimum width

Text Considerations

  • Sans-serif fonts are generally easier to read on a screen
    • Print serif fonts are, but light reflects off of paper where screen illuminates light
  • Text Sizing
    • Ensure font can be enlarged with out breaking the design
    • Headers should be larger than regular text (to indicate more importance)
    • Fonts should be decent size, not everyone knows how to resize text

Other Considerations

  • Limit the use of Flash
  • Print Style Sheets
  • Graphical buttons should be text with graphical backgrounds (for sizing without pixelation)
  • Include an access guide, or site help
  • No flickering
  • Audio–plan for text-only version and links
  • Video–plan for real-time captioning