W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2013

Re: Page length and number of links

From: David Hilbert Poehlman <poehlman1@comcast.net>
Date: Tue, 25 Jun 2013 10:00:23 -0400
Cc: W3C WAI ig <w3c-wai-ig@w3.org>
Message-Id: <1D662B29-5087-49CE-963A-8ED34CCDC38C@comcast.net>
To: Russ Weakley <russ@maxdesign.com.au>
I'd like not to mess with the content, just make the scroll controllable.

On Jun 25, 2013, at 8:59 AM, Russ Weakley <russ@maxdesign.com.au> wrote:

All these possible issues are great. One simple solution might be to provide users with the choice - endless scroll or paginated. The paginated option would allow users much more control over each page. This could be useful for any audience - not just AT audiences.

Thanks
Russ

> 
> 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
Received on Tuesday, 25 June 2013 14:00:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:49 UTC