Re: activedescendant in viewport (Re: [whatwg] scrollIntoView jarring?)

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Chair, IBM Accessibility Architecture Review  Board
blog: http://www.ibm.com/developerworks/blogs/page/schwer

david bolter <david.bolter@gmail.com> wrote on 05/02/2008 12:39:25 PM:

> Replying to myself below...
>
> David Bolter wrote:
> >
> > Hi Rich,
> >
> > activedescendant:
> > Great. If it will work for us, I feel better relying on the user agent
> > for bringing active descendants into view. I thought we were going to
> > require the DHTML author to perform a scroll of some kind?  If not,
> > great, and I agree it would appear to be a akin to tabindex. We should
> > definitely discuss one Monday or ping Aaron and others...
>
> I just chatted with Aaron over IRC.
>
> I think active-descendant probably shouldn't drive behavior in this way.
>
> Here's why: I'm thinking of the common use case for active-descendant
> today... and aria active-descendant, rightly or wrongly, is often going
> to be added after the DHTML widget behavior has already been
> implemented. This behavior would already, presumably, make sure that the
> thing(s) we want to attach active-descendant to are in the viewport. If
> adding aria active-descendant performs, via the browser, a redundant,
> and perhaps even slightly different scroll, that would be bad IMO. In
> fact, it could be very frustrating to authors.
>

Hi David,

yes. I heard Aaron's view on this but I think we are very early on in
activedescendant
usage and I am not convinced that authors will do the additional viewport
work. Also,
the intent is to reduce the amount of work an author needs to perform.
Requiring them to add
all this extra code, which they don't do if you were to replace
activedescendant with a tabindex
implementation, is an unneeded burden when the goal was to reduce code. I
would argue that this
will force authors to stay using tabindex as the user agent does the work
for them. Keep in mind
that if the author wanted to additionally ad a scrolltoview in addition to
moving tabindex they could do
so but this is only if the author felt it necessary.

Focus management and views has something traditionally left to the browser.

In any case, I have added it to Monday's agenda so that we can all discuss
further.

> Yeah let's chat about it.
>
> cheers,
> D
> >
> > scrollIntoView:
> > I'm not sure of the intended use cases of scrollIntoView, so for now I
> > still agree with Brad Fults, that horizontal scrolling shouldn't be
> > forgotten here. And if we want scollIntoView to butt the element to
> > the edge no matter what, that's fine, but we shouldn't expect that to
> > be received as the ideal/desired behavior by all. Couldn't we make it
> > optional?
> >
> > cheers,
> > D
> >
> >
> > Richard Schwerdtfeger wrote:
> >>
> >> David,
> >>
> >> To be honest, the right solution for this is to have the user agent
> >> do it like tabindex. Since activedescendant is not being adopted
> >> until FF 3, IE 8, Safari ?, and Opera ? all existing browser targets
> >> for web application developers should require the use of tabindex.
> >> So, why not make it consistent with how the browsers process tabindex.
> >>
> >> Further justification:
> >>
> >> activedescendant requires the browser to fire additional focus change
> >> events to the AT. It is intended to reduce the code the author has to
> >> write. ScrollIntoView is not available until HTML 5 as well.
> >>
> >> We can all discuss this on Monday's calls.
> >>
> >> Thoughts?
> >>
> >> Rich
> >>
> >>
> >> Rich Schwerdtfeger
> >> Distinguished Engineer, SWG Accessibility Architect/Strategist
> >> Chair, IBM Accessibility Architecture Review Board
> >> blog: http://www.ibm.com/developerworks/blogs/page/schwer
> >> Inactive hide details for David Bolter
> >> <david.bolter@utoronto.ca>David Bolter <david.bolter@utoronto.ca>
> >>
> >>
> >>                         *David Bolter <david.bolter@utoronto.ca>*
> >>                         Sent by: w3c-wai-pf-request@w3.org
> >>
> >>                         04/30/2008 03:43 PM
> >>
> >>
> >>
> >> To
> >>
> >> Peter Kasting <pkasting@google.com>
> >>
> >> cc
> >>
> >> whatwg@whatwg.org, W3C WAI-PFWG <w3c-wai-pf@w3.org>,
> >> public-html-comments@w3.org
> >>
> >> Subject
> >>
> >> Re: [whatwg] scrollIntoView jarring?
> >>
> >>
> >>
> >>
> >>
> >> Peter Kasting wrote:
> >> > On Wed, Apr 30, 2008 at 10:58 AM, David Bolter
> >> > <david.bolter@utoronto.ca <mailto:david.bolter@utoronto.ca>> wrote:
> >> >
> >> >     Specifically I would ask that:
> >> >
> >> >     1. scrollIntoView not do anything in the case that the element
is
> >> >     already fully visible (possibly in the middle of the viewport),
or
> >> >     2. ensureElementIsVisible to be added as described by Daniel
> >> >     Glazman
> >> >
> >> (http://lists.w3.org/Archives/Public/public-html/2007Nov/0188.html)
> >> >
> >> >
> >> > I agree that this is a use case which scrollIntoView does not seem
to
> >> > solve well.  I am not sure Daniel's proposal for
> >> > ensureElementIsVisible is perfect either, though it is clearly
better.
> >> >
> >> > I make no formal proposal, but the behavior I would typically want
for
> >> > some kind of a call (perhaps in addition to those above, I don't
know)
> >> > would be:
> >> >
> >> >     * If the element in question cannot be scrolled so as to make
more
> >> >       of it appear in the viewport, do nothing.  (For when the
element
> >> >       is completely visible, or is larger than the viewport and
> >> >       already taking up the whole viewport).
> >> >     * Otherwise, if the element is not larger than the viewport,
> >> >       scroll such that the element is centered* in the viewport
> >> >       (within the scrolling limits -- if the element is at the
bottom
> >> >       of the page, it clearly can't be scrolled up to the middle of
> >> >       the viewport).
> >> >     * Otherwise, scroll the element such that the top of the element
> >> >       is aligned with the top of the viewport.
> >> >
> >> > *Perhaps centered is the wrong choice.  Another suggestion would be
to
> >> > scroll to a point 1/3 of the way from the top or bottom of the
> >> > viewport, nearer to whichever edge the element scrolled in from.
> >> >  Also, perhaps the UA's behavior should not be specified in this
kind
> >> > of detail?
> >>
> >> Peter,
> >>
> >> Nice. I agree on all points, except maybe if larger than the viewport
we
> >> might want to butt an element corner to a viewport corner (perhaps
> >> top-left for left-to-right languages), but I also wonder if that is
too
> >> much detail.
> >>
> >> cheers,
> >> David
> >>
> >>
> >
> >
>