Re: [html-techs-tf] Agenda for 22nd October 2012

Hi y'all,

Here are the minutes from todays call. Many thanks to Marc for scribing. [1]

Apologies in advance for omissions and errors.

Cheers

Josh

[1] http://www.w3.org/2012/10/22-html-techs-tf-minutes.html

HTML techniques TF

22 Oct 2012

Topics
https://www.w3.org/2002/09/wbs/35422/22_10_2012/
ARIA Expandable
Summary of Action Items
<Joshue108> scribe: Josh
https://www.w3.org/2002/09/wbs/35422/22_10_2012/

<Joshue108> <discussion on Jons technique>
<Joshue108> LGR: This could be another tech suitable for 1.3.1
<Joshue108> Jon: Do you want more detail? Event handlers etc?
<Joshue108> Loretta: We should be telling people to look at what they 
have implemented, and what the tech is describing.
<Joshue108> LGR: The functional tests can be problematic in use.
<Joshue108> JG: So you're more interested in how you add keyboard 
support to any kind of widget.
<Joshue108> LGR: Thats what I am wondering.
<Joshue108> LGR: You can add tabindex="0", you may or may not use 
activedescendent etc.
<Joshue108> JG: Do you really want to promote people doing tabindex="0" 
on everything?
<Joshue108> LGR: We want to indicate best practice. In some cases, this 
may be perfectly fine.
<Joshue108> JG: So something about adding event handlers to partciular 
widgets.
<Joshue108> JOC: We should have something somehwere.
<Joshue108> JOC: We should have examples of where using tabindex is best 
practice and other where using event handlers or whatever is preferable..
<Joshue108> DF: We do have people who may to expect to reach things by 
tabbing thru, which is the method in most manu type cases.
<Joshue108> DF: So this tech may be fine for some browser AT combos, but 
in some cases in can lead to a loss of context etc.
<Joshue108> DF: There should be a disclaimer about use where the user 
base is known where proper AT and browser combinations are used.
<Joshue108> LGR: A technique would be a good place to have that discussion.
JG: I've seen companies use tab technique and felt that was a good 
technique - but let to thousands of tab stops
... Other models for keyboard - but not an ARIA technique at that point
... Big part of ARIA / ARIA techs would be to focus on authoring 
practices - because then when folks get to a menu, they know what 
behavior to expect
... Otherwise they're left wondering how a widget may act
<Loretta> 
http://www.w3.org/TR/2012/NOTE-UNDERSTANDING-WCAG20-20120103/keyboard-operation-keyboard-operable.html
DF: I wonder about those folks in install base that don't have latest 
browser / screenreader. They would be badly served by a widget that 
don't tell them. Perhaps tell users that will miss out on this that they 
need to use menu keys etc - how to operate
<Loretta> HTML non-ARIA technique: 
http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/SCR35
JG: Menu bar and menu navigation are two separate things
... In a menu instead of links you'll have menu items - you have to add 
event handlers. You have to look at that because something looks like a 
menu, you may not want to use ARIA to make it a "menu". If it's just a 
bunch of links there is already a bunch of built in AT support to navigate
... In general I see users overusing ARIA where they shouldn't use it.
... Can often add to overcomplicated designs. Menu is one of those items
DF: Sounds like a clear case to make a differentiation between the 
techniques
LGR: May be a 1.3.1 technique for menus where description tries to 
capture what instances you would use this markup for.
<Joshue108> +q
LGR: Issue where people are using where it's not appropriate is 1.3.1 - 
where people are trying to expose semantics w/ ARIA
... There is an existing technique - pre-ARIA - for making actions 
keyboard accessible
<Joshue108> Here it is again:
<Joshue108> -q
http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/SCR35
JOC: Sounds like Jon has hit on several techniques that we need
LGR: Willing to try to take existing keyboard technique and create a 
version that is an ARIA/HTML5 technique
<Joshue108> JOC: I'd like to help Loretta on that technique
<jongund> Uses tab or arrow keys for pull down lists of links: 
http://www.dhs.state.il.us/page.aspx?
<Detlev> sounds good!
JG: ARIA Authoring Practices outlines keyboard navigation - what 
different keystrokes should do for different widgets
LGR: Would you consider writing up a 1.3.1 technique for menus where you 
capture your understanding under what circumstances ARIA techniques 
could be used for menus?
JG: Yes. I think most of the navigation is just listed links, then just 
landmark navigation role is fine.
<Joshue108> JOC: Thats great, thanks Jon.
JG: I'll try writing it up and sending it. Something about the different 
types of menus
<Joshue108> 
http://www.w3.org/TR/WCAG20/#content-structure-separation-programmatic
JG: So it would be a technique on when it's good to use an ARIA menu? 
When it's good to use one - when not to use one?
LGR: I'm trying to think of the parallel for the technique of when it's 
appropriate to use Headings
JOC: Traditionally menus over the years have been Lists - but there is a 
disconnect on what these things may be and how you expect them to act
Agreement to write up draft and then discuss further when we have that draft
LGR: Two techniques for Jon - 4.1.2 using specific menu roles and 
properties and 1.3.1 when to use menu, menubar roles
ARIA Expandable

<Loretta> 
https://www.w3.org/2002/09/wbs/35422/htmltechs20121005/results#xtree
JG: Don't believe ARIA has the concept of a static tree
LGR: I pulled that example out of the ARIA spec
JG: To me it's just a nested list - not sure why we should put ARIA on 
it. I'll ask Rich S what the use case would be
LGR: Certainly not interactive in the sense of expand or collapse
<jongund> I need to go
JOC: Will look at this expanded state in a tree widget technique next week
Summary of Action Items

[End of minutes]

Received on Monday, 22 October 2012 17:56:31 UTC