7016 2009-06-12 18:29:28 +0000 Determine if we need a section on default style sheets for WAI-ARIA 2009-09-15 16:01:28 +0000 1 1 1 Unclassified ARIA Core AAM 1.0 PC All RESOLVED LATER P5 normal --- 1 andi.snowweaver cyns aria-ua-impl oldest_to_newest 25557 0 andi.snowweaver 2009-06-12 18:29:28 +0000 25558 1 andi.snowweaver 2009-06-12 18:31:47 +0000 Removed this bullet from section on Controlling focus with tabindex: The default style sheet must include rules so that any element with :focus receives a focus outline. 26039 2 andi.snowweaver 2009-07-22 14:07:45 +0000 July 20, F2F, Boston: In addition to focus, do we also have some rendering things? Add section of recommendations (should, not must). ariaactivedescendant implications (see bug 7020) - can't use a pseudoclass to draw focus around a particular childid If use desktop focus for active descendant, then this is OBE. 27097 3 cyns 2009-09-11 23:14:54 +0000 I see two issues here 1) how to handle focus. I feel pretty strongly that this should be done using the desktop focus. Desktop focus is configurable in the OS, and has a known relationship with AT products. Creating a separate, fake focus opens up all sorts of issues and inconsistencies that go away if we use desktop focus. 2) Rendering defaults based on aria attributes. Should <div aria-role="button"> render like <button> by default? I think probably not at this point. If it starts creating button behavior in teh browser, than yes, but that's not the case now. This is probably too hard to get right in this timeframe, at least for things that have native HTML implementations. It might make sense to have a default rendering for tree and some of the other things that don't exist in HTML. But, wouldn't designers override that default rendering most of the time anyway? I think we should not take this on at this point. 27157 4 cyns 2009-09-14 21:38:42 +0000 The explanation in the ARIA spec is more clear. We should either copy that one here, move it here, or remove it from our document. I'm not sure I agree with the idea of the user-entered value of a form element contributing to the name... That should be the value in a name/value pair, not part of the name. That's what IE does. Does FF add the user-entered value to the name now? Let's make a new bug on that, and close this one using the spec text. 27187 5 andi.snowweaver 2009-09-15 16:01:28 +0000 Cynthia's last comments above were meant for bug 7064. WRT Cynthia's previous comments: >1) how to handle focus. Focus issue is covered by bug 7020 >2) Rendering defaults based on aria attributes. Not for this round. Consider for UAIG 2.0.