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 viewport 

* 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 viewport

* 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.