This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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>
mass-moved component to LC1
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: If someone writes a program that converts HTML files to PDF files, and has a "preview" mode that shows the PDF file, it is an interactive program that accepts user input, but it would still just be a non-interactive presentation user agent, and that would not be inappropriate (on the contrary, it would make no sense for such an application to be any other conformance class). So I don't think the "should" you are suggesting is an appropriate requirement. At the end of the day, a developer writing an application so limited in scope that they only designed it for one input modality isn't going to be swayed by this section. Imelda should just switch to a better vendor (of which there are many). Note also that making the sample limited applications you describe accessible is much easier than making it support the entire suite of HTML APIs and interaction features. What you are suggesting would require that the application that displays a static Web-based slide also support interactive HTML form controls, which sounds like it would be way out of the scope of what such an application should be doing. Just because you're not a full Web browser doesn't mean you shouldn't be accessible. Any commercial application on a general purpose computer should be accessible to all users of that computer, that's got nothing to do with the HTML spec and everything to do with simple ethics and common sense.