This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 8715 - Scrolling elements into view
Summary: Scrolling elements into view
Status: VERIFIED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Joshue O Connor
QA Contact: HTML WG Bugzilla archive list
URL: http://dev.w3.org/html5/spec/editing....
Whiteboard:
Keywords: a11y
Depends on:
Blocks:
 
Reported: 2010-01-11 19:55 UTC by Joshue O Connor
Modified: 2010-10-05 15:17 UTC (History)
6 users (show)

See Also:


Attachments

Description Joshue O Connor 2010-01-11 19:55:43 UTC
As the scrollIntoView([top]) method is all about giving focus it is important that the needs of non-visual users are covered in a more explicit way.

The spec currently states that:

"Non-visual user agents may ignore the argument, or may treat it in some media-specific manner most useful to the user." 

This seems very vague.

Should the spec not offer more concrete advice? Such as:

"Non-visual user agents may provide focus to the top most relevant element within the window view, for example by giving focus to the most relevant heading when the method is called. This will help users of Assistive Technology such as a screen reader, orientate themselves.

Where there are no relevant elements, then non-visual user agents may ignore the argument, or may treat it in some other media-specific manner that would be most beneficial to the user".
Comment 1 Ian 'Hixie' Hickson 2010-02-06 09:31:53 UTC
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: Did Not Understand Request
Change Description: no spec change
Rationale: I don't understand. "Non-visual user agents may provide focus to the top most relevant element" doesn't make sense to me. How can there be a top-most anything if it's not a visual UA?
Comment 2 Joshue O Connor 2010-02-08 11:54:08 UTC
Ian said:
>I don't understand. "Non-visual user agents may provide focus to the
>top most relevant element" doesn't make sense to me. How can there be a
>top-most anything if it's not a visual UA?

The notion of a 'view' is relative in different modalities. Some users are sighted, some not. A sighted person may glance at a page and quickly understand context etc, a non-sighted person may need to be able to easily navigate to an area of the page, or quickly tab to various elements to be given this sense of context. Do you follow?

If so, there should be a way of supporting a non-visual mode of access (the spec currently refers to it as "media-specific manner most useful to the user"). I suggest the text needs to be more specific in /how/ to do this. In its simplest terms - this could be for example, a parent element in the DOM etc.
Comment 3 Michael Cooper 2010-02-11 17:26:46 UTC
Per the proposal at http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0245.html, the HTML A11Y TF does not plan to formally work on this issue at this time. This does not mean the TF has no interest in it, but does not have immediate plans to work on it. The TF may review the issue in the future.
Comment 4 Ian 'Hixie' Hickson 2010-02-17 22:19:55 UTC
> The notion of a 'view' is relative in different modalities. Some users are
> sighted, some not. A sighted person may glance at a page and quickly understand
> context etc, a non-sighted person may need to be able to easily navigate to an
> area of the page, or quickly tab to various elements to be given this sense of
> context. Do you follow?

I am in fact quite well acquainted with matters of accessibility, yes.


> If so, there should be a way of supporting a non-visual mode of access (the
> spec currently refers to it as "media-specific manner most useful to the
> user"). I suggest the text needs to be more specific in /how/ to do this. In
> its simplest terms - this could be for example, a parent element in the DOM
> etc.

As far as I can tell, this is requesting some concrete examples of what scrollIntoView() might do in browsers for different media. But if that's what is being requested, then why is the spec not sufficient? The very *first* media it talks about is speech browsers. It mentions these even before visual (screen) browsers. The method is defined in terms that are completely media-independent.

Maybe the bug report is only about the argument to the method? But in that case I don't understand why anything needs to happen. Why would we want to apply a visual attribute to a non-visual UA? I don't understand how the attribute would even make sense in a braille or speech medium, for example.

What does "a parent element in the DOM" have to do with this?

I'm very confused as to what is being requested.

Could I ask for some sample text that you would want the spec to have that would satisfy this bug report?


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: Did Not Understand Request
Change Description: no spec change
Rationale: see above
Comment 5 Michael Cooper 2010-09-28 15:18:32 UTC
http://www.w3.org/2010/09/28-a11y-bugs-minutes Josh to provide more information on this issue.
Comment 6 Joshue O Connor 2010-10-05 15:17:41 UTC
Am unsure, on reflection if this is an issue. The notion of scrolling etc is a rendering within the visual browser, elements within the source code should still be focusable  either way. I suggest either closing the bug.