W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > August 2011

[Bug 13655] New: Support for viewports and positions

From: <bugzilla@jessica.w3.org>
Date: Thu, 04 Aug 2011 01:59:04 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-13655-2486@http.www.w3.org/Bugs/Public/>

           Summary: Support for viewports and positions
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: a11y
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: gcl-0039@access-research.org
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org, public-html-a11y@w3.org

Need to make sure that HTML5 fully supports the ability for accessibility aids
to work with the visual representations of elements and the viewports in which
they're presented. 

These include but are not limited to the ability for scripts to:

* determine which portion of content is currently in the visible portion of the

* scroll the viewport vertically and/or horizontally so that a particular
element or range is in view, or to a particular position

* determine which element is at a particular location relative to the screen
and/or content of the viewport (hit testing). For example, can a script
determine which element is under the mouse pointer, or at the upper-left corner
of the visible portion of the viewport, and then use the DOM to interact with
that element? Since almost all user agents are already set up to do this, it
would make no sense to make scripts walk through the entire DOM checking the
coordinates of each element.

* determine an element's position relative to the screen and/or content of

* determine the locations of both the focus element and, if it exists, the text
cursor within that element

Use case: Boris has difficulty scanning the page for changes. When he searches
for text or presses the Tab key, he would like to have the search results or
focused element centered vertically on the screen so that he can locate them
more easily. Since his browser doesn't do this, he runs an add-in that detects
focus changes, determines whether the focused element is within a range of the
vertical center of its containing viewport, and if not scrolls the viewport to
make it so.

Use case: Tanya uses the keyboard exclusively, and a browser add-in that
creates a single-character keyboard shortcut for each focusable element and
adds that character in brackets next to the element. Giving a shortcut to every
focusable element in the very large documents would not only be prohibitively
slow, it would also require using increasingly obscure or lengthy shortcuts, so
the add-in wants to assign and display shortcuts only for those elements that
are in the visible portion of the viewport.

Use case: Jonathan uses the keyboard exclusively. While a mouse user can scroll
a viewport without affecting selection and focus, Jonathan's browser does not
provide a keyboard mechanism for this: he can only scroll the viewport by
moving the focus. He installs a script that adds keyboard commands for
scrolling vertically by a few lines, by a viewport height, to the top and
bottom, and to a specified location, and the equivalents horizontally. 

Use case: Laurie is developing a web application that lets users manipulate
visual representations of data. Because this requires fine motor control and
keen vision, she wants to add a window that shows a magnified view of the area
around the mouse pointer. 

Use case: Conrad has difficulty keeping track of context, so he runs a browser
add-in whose script provides feedback as to where he is in the document,
supplementing normal scroll bars with an overview window that shows the entire
document and highlights the region that's currently visible. 

It is not immediately clear how much of this can be done in browse-independent
fashion with HTML5. In the past, some of it was possible only with non-standard
Window objects. Richard Schwerdtfeger believes proposals or bugs have been
filed on some but not all of these requirements.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 4 August 2011 01:59:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:59 UTC