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

On Nov 28, 2011, at 9:17 AM, Sailesh Panchang wrote:

>> widget uses are likely to require aria-activedescendant and roving tabindex.
> Sailesh: Can this not be managed by altering tabindex value via
> JavaScript?  Setting it to "-1" for the parent element and "0" for
> child elements is the way I thought this is to be accomplished.
James: the text you quoted was not mine, but I don't think doing this would work for something like flexbox or some of the other new CSS3 layout modules.


> 
>> 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.
> Sailesh: Well I still think it is structure and semantics  that affect
> reading order / nav order and should be handled via HTML markup.
> This is sort of akin too  switcyhing alt values when image replacement
> method is used or switching text to reveal state of an element like
> "show content" / "hide content". If the content has navigable elements
> they have to be in proper nav order. If CSS causes content to be
> re-ordered, then CSS is not strictly being used for presentation in a
> manner that does not impact semantics / structure. The role of
> managing nav order should be retained within HTML.
> My concern primarily is how will conflict be handled when CSS and HTML
> both specify  a nav order and will it become messy  and cause
> confusion for developers as well as for testers / testing ttools.
> Sailesh Panchang

James: The structure vs presentation argument has already been lost to many web developers. Semantics are being presented in all of CSS, HTML and JS on many modern web sites. Aren't we better to give developers the tools to make these new techniques accessible rather than preach the same argument to them which they will (again) ignore if it makes their life easier?

Regards,
James

> 
> On 11/28/11, James Nurthen <james.nurthen@oracle.com> 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 03:32:09 UTC