Category: navigation

Infinite Scrolling and Accessibility (It’s Usually Bad)

Post author By Dennis
Post date August 25, 2015
10 Comments on Infinite Scrolling and Accessibility (It’s Usually Bad)

Experts say don’t do infinite scrolling, or be extremely careful in doing so. I completely agree. Infinite scrolling creates accessibility and usability problems. Below are checkpoints, issues and suggestions from a few resources.

Here’s a great list of checkpoints from the article So You Think You’ve Built a Good Infinite Scroll by Adrian Roselli (@aardrian):

Can the user hit “back” and return to the exact same place?
Is there paging for when the JavaScript breaks?
Does the page have a footer?
Can a keyboard user access all other content on the page?
Can you share a URL to a specific place on the page?
Can a user easily jump ahead a few “pages” to quickly get to content much further down the list?
Does the memory footprint of the page dramatically increase after just a couple new “pages?”
Is there a way to disable automatic infinite scrolling and lean on standard paging?
Have you conducted any user tests?
Are you satisfying a use case that has come from research or user request?
Do you have any analytics/tracking to measure success?

In the article Infinite Scrolling: Let’s Get To The Bottom Of This, Smashing Magazine makes some great points including the following.

Fails: temptation, optimism, exhaustion, pogo-sticking, loss of control, distracting, unreachable

Users want immediate access to exclusive data.
Users want to feel in control.
Users often look for landmarks when scrolling.
Consider conventional pagination or a hybrid solution.
Provide interesting content without an ambiguous interface.
Users often expect a footer.
An infinite list is still a list.
Effects are nice to have but not a must.

In the Simply Accessible article Automatic infinite scrolling & accessibility, Derek Featherstone (@Feather) says:

Just don’t implement infinite scrolling.
Replace automatic infinite scrolling with a “Load more results…” button or link that explicitly invites the user to add more. Once they do a few times, prompt them to ask if they’d like to turn auto-loading of more results on.
No, really, just don’t implement infinite scrolling.

The CA.gov Web Site Accessibility Page

Post author By Dennis
Post date June 10, 2010
10 Comments on The CA.gov 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.

Addendum

The CA.gov Accessibility Page Updated!

aria navigation screenreader

Screen readers and navigation

Post author By Dennis
Post date January 21, 2010
No Comments on 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:
http://www.w3.org/WAI/PF/HTML/wiki/Access

2. Accesskey Replacement Requirements (approved by PFWG years ago):
http://www.w3.org/WAI/PF/HTML/wiki/Access/access_key_requirements

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:
http://www.w3.org/WAI/PF/HTML/wiki/Access/element_versus_module

4. rob burns’ (robburns1 on twitter) Command & Event and Keyboard
Focus Module:
http://www.w3.org/WAI/PF/HTML/wiki/Access/command_and_event

the
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

code color design layout navigation podcast text

Podcast #34: Design Considerations for Accessibility

Post author By Dennis
Post date November 17, 2006
1 Comment on 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