- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 14 Jul 2011 14:12:09 -0700
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: public-html@w3.org, Anne van Kesteren <annevk@opera.com>, Jonas Sicking <jonas@sicking.cc>
On Thu, Jul 14, 2011 at 5:16 AM, Sam Ruby <rubys@intertwingly.net> wrote: > First, thanks to Tab, Jonas, and Anne for your feedback on issue 134. > > I'd like to draw your collective attention to the fact that we have a > long-standing policy[1] of allowing issues to be reopened based on new > information and a concrete change proposal. > > I encourage each of you to consider submitting a change proposal on this > matter. Sure. I'd like to submit a request to reopen. New Data ======== 1. The "Details" part specifies that "User agents must manage focus for the tab controls by ensuring that only the selected tab is focusable, and that the remaining tabs in the tablist menu are not focusable.". However, the "Risks" section states without such an element, developers might make "only the selected tab in each tablist... focusable, meaning that the remaining tabs from each tablist will not be available or accessible to assistive technologies.". Is this a good or bad thing? 2. In "Details", "tabpanel" is listed as a state for <command> elements, but later text seems to suggest that it should be an attribute on <command> elements that takes an IDREF. 3. The CP doesn't indicate what the proposed changes should *do*. The intention is clearly to make it easier to do cardstacks, where you have a list of tabs associated with cards, and only one card is visible at a time (and its tab is specially indicated in the tablist). But nothing like that is specified anywhere. It appears that authors would still need to use script to create this kind of UI. 4. This is fundamentally a CSS issue. I've thought about this exact problem before, and while I suspect there *may* be something we need to do at the host-language level to connect tabs to cards, that conclusion should only come after some research has been put into the problem by the CSS Working Group. 5. An Opera representative has stated that Opera would not implement this proposal. A Firefox representative has expressed doubts that this is an appropriate solution to the stated problem. I (a Chrome developer) also believe this is not an appropriate solution to the stated problem. Counter Change Proposal ======================= Summary ------- No change. Rationale --------- The stated problem should probably be solved with CSS, as it is an issue of presentation. If it is best solved in HTML, it is likely *not* through the provided solution, which overloads the <menu> and <command> elements with additional semantics, similar to the known anti-pattern exemplified by <input>. Benefits -------- A bad solution is not adopted. Work is not misspent on bad solutions that could instead be spent on investigating a good, CSS-based solution. Risks ----- Tablists continue to be fiddly to implement in a fully accessible way for an extended period of time. They've been that way for years, though, so this isn't a new issue. ~TJ
Received on Thursday, 14 July 2011 21:13:00 UTC