[Bug 13442] New: Clarify cases that should NOT be "non-interactive presentation user agents"

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13442

           Summary: Clarify cases that should NOT be "non-interactive
                    presentation user agents"
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: a11y, a11ytf
          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


It is very important that developers should not relegate user agents to the
"non-interactive presentation" category if there is benefit to the user in
being able to interact with them.

Recommendation: The HTML5 spec section 2.2.1 (Conformance classes) should
include wording that clarifies that user agents should not consider themselves
non-interactive if they render content to the user on any system that can take
input, and more specifically should not omit support for focus-related DOM APIs
just because they do not expect to be taking input. Ideally it would include
use cases similar to the above in order to help readers understand the issue. 

Sample wording: "User agents should not be considered non-interactive
presentation user agents if they render content to the user on any system that
takes input, and more specifically should not omit scripting support and
focus-related DOM APIs just because they do not expect to be taking input. For
example, accessibility aids may need to communicate with a web browser to allow
caret browsing for static content even in a web-based application that is
intended to be non-interactive."

Use case: Imelda uses a screen enlarger. She runs an application that displays
a static, web-based slide detailing today's weather forecast. Imelda uses a
screen enlarger, and normally reads blocks of text by having the magnifier
track the text caret as she moves it through the content. However, as the
developers considered theirs a non-interactive user agent, they left out the
ability to do caret browsing. With luck, the screen enlarger will be able to
access the application's DOM and determine the screen coordinates of each word,
but it would certainly be easier if the application supported caret browsing.

Use case: The weather application that Imelda is running allows the user to
select text with the mouse and automatically copies that text to the clipboard.
However, the developers did not consider this "focus" or "activation", or even
"selection" because the selection does not persist and the user can't perform
their choice of actions on it. However, by this decision they are making
functionality available to only one input modality, and users who rely on other
modalities such as keyboard or speech recognition are denied full access. In
this case, the developers should not have considered their application
non-interactive, and instead implemented full focus and selection
functionality.

The current draft HTML5 spec in section 2.2.1 (Conformance classes) says:

<blockquote>

    Non-interactive presentation user agents 

    User agents that process HTML and XHTML documents purely to render
non-interactive versions of them must comply to the same conformance criteria
as Web browsers, except that they are exempt from requirements regarding user
interaction. 

    Typical examples of non-interactive presentation user agents are printers
(static UAs) and overhead displays (dynamic UAs). It is expected that most
static non-interactive presentation user agents will also opt to lack scripting
support. 

    A non-interactive but dynamic presentation UA would still execute scripts,
allowing forms to be dynamically submitted, and so forth. However, since the
concept of "focus" is irrelevant when the user cannot interact with the
document, the UA would not need to support any of the focus-related DOM APIs. 

</blockquote>

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Thursday, 28 July 2011 23:51:57 UTC