- From: David Hilbert Poehlman <poehlman1@comcast.net>
- Date: Tue, 25 Jun 2013 10:00:23 -0400
- To: Russ Weakley <russ@maxdesign.com.au>
- Cc: W3C WAI ig <w3c-wai-ig@w3.org>
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