RE: Page length and number of links

> While I understand the reasoning behind such a move, I honestly believe
it would be better to find out how to make endless scrolling accessible
(and then demand that it actually be made accessible).

I agree.  I wasn't trying to say that pages could not provide endless
scrolling but there needed to be a method to pause, stop, hide, or make it
accessible.  For example, this would work much in th same way as the
dynamic content requirements.  ARIA can be used to alert screen readers
that new content appears -- perhaps several techniques including ARIA
could be used.  There are also issues regarding how browsers work with the
keyboard that would need to be addressed perhaps in the UAAG.  This issue
clearly affect multiple user groups in different ways.

It's important to understand the issues that this implementation causes in
order for sufficient techniques to be created to make it accessible.  Here
is a list of possible issues:
1. No way to locate the bottom of the page (end of content -- if it
exists)
Commands like control+end don't move to the actual end and may produce
different results when pressed from different locations on the page.  When
screen readers are active it may not be possible in all situations for the
user to scroll the content while using the up and down arrow keys.  The
location with the page changes and the user may not know that the page can
be scrolled.  There is no indication that the page can be scrolled until
it occurs as the page's scrollbars only indicate the location within the
current rendition of the page.

2.  Moving to the top of the page may cause the page to constrict thus
loosing access to content that was previously displayed.

3. The technique may not be accessibility supported by assistive
technology.
Pages with tens of thousands of links, headings, etc. may bog down a
screen reader to point it isn't usable

4. Keyboard access to links may be difficult or impossible.  For example,
the user may have to tab thousands of times to reach a link that can
easily be clicked via the mouse.

The issue stems from how browsers keep the keyboard focus on the last
element focused and do not move keyboard focus to a page where the page is
scrolled. Thus, even if a keyboard user can scroll the page with page
down, space, or control+end, pressing the tab key will place the focus on
the element after the element that previously had focus and thus the
screen is scrolled back to where it was previously.  Caret browsing does
not solve this issue in my experience.

Jonathan

-----Original Message-----
From: Olaf Drümmer [mailto:olaf@druemmer.com]
Sent: Tuesday, June 25, 2013 7:06 AM
To: Jonathan Avila; W3C WAI ig
Cc: Olaf Drümmer
Subject: Re: Page length and number of links

On 24 Jun 2013, at 14:59, Jonathan Avila wrote:

> This is good news that the WCAG WG may consider creating a failure for
> endless scrolling!  Skittles.com is a good example of this.

While I understand the reasoning behind such a move, I honestly believe it
would be better to find out how to make endless scrolling accessible (and
then demand that it actually be made accessible).

Endless scrolling can provide a very useful user experience at least for
some types of content and for for some users, and should not be declared
unaccessible just so.

Olaf

Received on Tuesday, 25 June 2013 12:50:03 UTC