W3C home > Mailing lists > Public > wai-xtech@w3.org > November 2011

Re: [css3-ui] scoping 'nav-index' (or tabindex) for large document use cases

From: Sailesh Panchang <sailesh.panchang@deque.com>
Date: Tue, 29 Nov 2011 12:04:00 -0500
Message-ID: <CAJi9Cqq9hTgXN2YukMpKtjs-MDoHoAthc00oMj-MVBcv5KTqyw@mail.gmail.com>
To: Chris Blouch <cblouch@aol.com>
Cc: James Nurthen <james.nurthen@oracle.com>, wai-xtech@w3.org
I like the idea of tabbnext and tabprev. If present, it will force tab
to move to stated attribute value by skipping certain elements as the
situation demands; else it will follow usual tab behavior. It may be
possible to use these without tabindex being used generally on the
page too.
Sailesh


On 11/29/11, Chris Blouch <cblouch@aol.com> wrote:
> Sure. We could also go over the top with a tabclass where tabbing around
> rotates through all elements of class="xyz", but that's probably fraught
> with implementation issues as we would want to ignore the cascade of
> class to contained elements. I was trying to figure out how to more
> easily restrict tab order within a faked modal dialog. Today we put an
> invisible focusable "bumper" element right after the last element in the
> dialog. When focus lands on the bumper an onfocus handler moves it back
> to the first element in the dialog (likewise a bumper is required at the
> top for shift-tab). If I could just mark all elements in the container
> with a class and somehow restrict tab order to that class it would
> eliminate a bunch of scripting and make the html behavior a bit more
> transparent.
>
> CB
>
> On 11/28/11 6:51 PM, James Nurthen wrote:
>> Wouldn't you also need a tabprevious?
>>
>> On 11/28/2011 2:22 PM, Chris Blouch wrote:
>>> Not to generate a rabbit trail, but if we're talking about new
>>> tabindex behaviors would it be possible/advisable to have a tabnext
>>> attribute with an ID? Would sure simplify a lot of things for
>>> managing focus on dynamic sites. So I put tabnext="xyz" on node and
>>> as long as some other container has that ID my next tab stop lands
>>> there, irregardless of its current tabindex value. Maybe this was
>>> already discussed and tossed but I like the option of being able to
>>> have one element decide where to push focus next rather than hoping
>>> the tabindex on the destination I want happens to play correctly with
>>> all the other tabindex values. The whole management of integer
>>> assignment of tabindexes to nodes just feels klunky and doesn't hold
>>> up well when pages, content and widgets are dynamically modifying
>>> their node hierarchies.
>>>
>>> CB
>>>
>>> On 11/28/11 11:32 AM, James Nurthen wrote:
>>>> Some new CSS3 layout regions cause content to be reordered. In order
>>>> to support keyboard navigation of this content it may be necessary
>>>> to define nav-index in CSS as well.
>>>> Regards,
>>>> James
>>>>
>>>> On 11/26/2011 4:09 PM, Sailesh Panchang wrote:
>>>>> It is not clear why the same functionality is being proposed via
>>>>> tabindex and CSS nav-index.
>>>>> I even wonder if CSS should do this. After all, tab order relates to
>>>>> document structure, meaningful reading / nav order and is concerned
>>>>> with semantics. Hence it should be addressed by HTML and its
>>>>> attributes not by CSS which, broadly speaking, addresses doc
>>>>> presentation / appearance aspects.
>>>>> And it will be very  confusing for developers as well as
>>>>> QA/accessibility evaluation tools if similar features can be
>>>>> implemented by tabindex in HTML and  nav-index in CSS.
>>>>> Sailesh Panchang
>>>>> www.deque.com
>>>>>
>>>>> On 11/20/11, Ojan Vafai<ojan@chromium.org>  wrote:
>>>>>> FWIW, there's a proposal to extend tabindex with tabindexscope to
>>>>>> address
>>>>>> the same problem:
>>>>>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-November/033775.html.
>>>>>>
>>>>>>
>>>>>> I agree that if we're going to add nav-index, we should also
>>>>>> address the
>>>>>> scoping problem.
>>>>>>
>>>>>> On Sun, Nov 20, 2011 at 3:22 PM, L. David
>>>>>> Baron<dbaron@dbaron.org>  wrote:
>>>>>>
>>>>>>> One of the issues that came up in the joint meeting between CSS and
>>>>>>> WAI Protocols&  Formats at TPAC (on October 31) was the 'nav-index'
>>>>>>> property in http://dev.w3.org/csswg/css3-ui/#nav-index .  (This is
>>>>>>> the second of two messages (on different topics) to follow up on
>>>>>>> that
>>>>>>> discussion.)
>>>>>>>
>>>>>>> There was a brief discussion that both 'nav-index' and tabindex are
>>>>>>> difficult for authors to use on large pages.  This was because of
>>>>>>> the impression that one of the use cases is likely to be doing a
>>>>>>> small amount of reordering of the tabbing order.  In particular, I
>>>>>>> think the following two use cases may have been brought up:
>>>>>>>
>>>>>>>   (1) The author wants to say that the tabbing order (sequential
>>>>>>>   navigation order) should be assigned a certain way for large
>>>>>>>   sections of the page, each of which contain many navigable items.
>>>>>>>   For example, consider two div elements, each with a large number
>>>>>>>   of links in it, where the author wants all of the elements in the
>>>>>>>   second div to appear in the tabbing order before all of the
>>>>>>>   elements in the first div.  This currently requires assigning
>>>>>>>   tabindex, at a minimum, to all the tab-navigable elements in at
>>>>>>>   least one of the divs, if not all the tab-navigable elements in
>>>>>>>   the whole document.  It would be easier if there were a way to do
>>>>>>>   this by applying styles only to the divs (and perhaps their
>>>>>>>   container; see item (2)).
>>>>>>>
>>>>>>>   (2) The author wants to say that the tabbing order (sequential
>>>>>>>   navigation order) should be assigned a certain way for a group of
>>>>>>>   elements within a specific container without having to specify the
>>>>>>>   order for everything else around them.  Right now, saying that two
>>>>>>>   links inside a div should be reached in the order opposite the
>>>>>>>   default one, but should appear in-sequence relative to the content
>>>>>>>   outside of the div, requires not only specifying 'nav-index' or
>>>>>>>   tabindex on the two links, but also on all the other links in the
>>>>>>>   document.
>>>>>>>
>>>>>>> It seems useful to be able to address these use cases by assigning
>>>>>>> properties or attributes to only a few elements rather than having
>>>>>>> to do so globally.
>>>>>>>
>>>>>>> (Note the desire for the tabbing order to be the way it is may be
>>>>>>> the result of positions assigned in the style sheet, which is why
>>>>>>> the tabbing order may belong in the style sheet as well.)
>>>>>>>
>>>>>>> I don't recall concrete proposals for how to address these issues,
>>>>>>> but they seem likely to be worth addressing in css3-ui.
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>> --
>>>>>>> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
>>>>>>> 𝄢   Mozilla                           http://www.mozilla.org/   𝄂
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>>
>
>
Received on Tuesday, 29 November 2011 17:04:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:16:12 GMT