- From: Chris Blouch <cblouch@aol.com>
- Date: Tue, 29 Nov 2011 10:55:53 -0500
- To: James Nurthen <james.nurthen@oracle.com>
- CC: wai-xtech@w3.org
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 15:56:33 UTC