See also: IRC log
<LJWatson> zakim this is 92463
<kooje> my last name is ku
<kooje> my first name is Jaeun but I would go by Jemma
<kooje> I am from University of illinois, urbana-champaign
<kooje> my phone number starts with 217
UNKNOWN_SPEAKER: git wiki here
https://github.com/w3c/aria/wiki/Aria-Authoring-Practices
<scribe> scribe: jamesn
<MichaelC> ackme
https://rawgit.com/w3c/aria/master/practices/examples/link-design-pattern/links.html
rawgit.com
took this https://github.com/w3c/aria/blob/master/practices/examples/link-design-pattern/links.html
and pasted into rawgit.com
MK: Main question is should we
include notes
... 1 thing i noticed is that you don't get a link context menu
when you right click on a link coded this way. One thing that
we might want to talk about in the notes
... they wouldn't be able to know how you are getting the
target. Some of the context menu actions wouldn't work
BG: depends what they are using
it for
... There isn't really anything that fits the UI
... It is up to the author if they want to do this
JN: I don't think it is an accessibility issue - and don't think FF would consider this a bug
MK: Where in the guide do we want
to include info about what works in what browser etc.
... I would much rather see that in the examples
LW: who is going to keep that up to date
BG: JF was putting together an aria compatibility matrix or has been talking aout it
LW: tried for something at CSUN but didnt get off the ground
MC: tets harness not working right now
LW: are there plans to keep that up to date
MC: the latest decision was to keep it up to date but has always been a stopgap tool.
MK: there is an opportunity to use these as test cases. the examples might facilitate test cases
MC: might want to consider test
the web forward framework
... designed around script based automated testing of
features
LW: would like to know more about this anyway
<MichaelC> http://testthewebforward.org/
MC: link for docs and getting
started
... writing tests and running tests
... in theory not limited to the kinds of tests they document
there. in practice get the most benefits if using the kind of
tests they already have support for.
LW: don't think this changes my stance
MC: WCAG has moved to an auxiliary page
<kooje> can you tell me what testing tool we are talking about?
MC: also an accessibility support DB project
JN: sounds like the best fit we have so far
<kooje> never mind
<MichaelC> http://www.w3.org/WAI/accessibility-support/
LW: circling back to including
notes with examples
... good to get a general format of what we want to include in
these examples
<LJWatson> http://ljwatson.github.io/ARIA-examples/link-examples/links.html
BG: like the idea of the basic
markup. Keyboard support needs to be there.
... combining with refs to w3c tutorials would also be good
MK: don't want to repeat what is
in the APG
... but something to explain what is implemented.
... how many people need stuff explained why certain things are
there.
... really like the phrases like where it says the span element
is not natively interactive
<kooje> I agree.
BG: link to a checklist within the aria bpg guide which indicates that span not a native element etc.
<kooje> I like the idea of explaining of the clear purpose in the notes.
BG: a kind of footnotes kind of
thing might be useful
... if there was a general guidance section.
<kooje> can use a different label, not "notes"?
MK: precede with something specific and then add generic stuff
BG: There are going to be a lot of commonalities between thjinngs with for example aria-activedescendent
MK: the other thing to keep in
mind is that things like combobox could end up with multiple
examples
... when we do that I am envisioning 1 page with multiple
examples
... probably each would have 1 set of notes
BG: I agree
<kooje> as a developer, I felt confused because there are so many options
JN: sometimes makes pages more difficult to write
BG: have been building out some
samples. Sometimes the requirements to make things accessible
are very different
... sometimes the requirements vs a readonly element varies
quite a bit across devices
Describing the differences is very important
BG: you have to use different attributes and techniques
MK: A table that lists the examples in the APG could accomplish this
<kooje> table idea sounds good
JN: brief description in APG is useful
MK: hopefully will allow us to create a repeatable pattern
BG: if typing into an editable
combobox that is fine. Need to be able to navigate left and
right within the textbox. There has to be some sort of
scripting behaviour.
... there are variations that don't translate equally
JN: some things sound like screen reader issues
LW: have enough to create more notes for links
Will not meet Nov 28, Dec 26 or Jan 2
<kooje> ok
<mattking> http://www.w3.org/WAI/PF/aria-practices/#checkbox
MK: this is what got us into the keyboard handling part
<mattking> http://www.w3.org/WAI/PF/aria-practices/#button
MK: I am going to propose some
changes to the keyboard handling section
... something that explains the fundamentals of focus
management
<kooje> As a newbie to the group, is there any way I can help? It would be nice if I can do shadow work of one of members.
MK: gets deep fast... would be
nice if in section 3 there was something that was higher
level
... want to link to this - and takes too long to get to what is
relevant
JN: too many words...
MK: some bits more important to
toolkit writers or screen reader users.
... fewer than half the words are needed
JN: I think we should give people some guidance as to what is and what is not a toggle button.
MK: should mention that there are
3 different types of buttons
... just a link to menu button
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27327
MK: a toggle button label shouldn't change when its state changes
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27328
JN: there are cases where you do want focus to move from a button for example add a new search criteria - you want to move to the new crtieria
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27329
MK: going to take out references
to external examples
... as we replace them
... stop here now
<kooje> I cannot hear anything
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: jamesn Inferring ScribeNick: jamesn Default Present: +1.217.244.aaaa, +1.650.738.aabb, Matt_King, James_Nurthen, LJWatson, Bryan_Garaventa, Jemma_Ku, Michael_Cooper Present: +1.217.244.aaaa +1.650.738.aabb Matt_King James_Nurthen LJWatson Bryan_Garaventa Jemma_Ku Michael_Cooper Agenda: http://www.w3.org/mid/117FD62B-F19D-4AAD-BD7E-99D77B1A5895@oracle.com Got date from IRC log name: 14 Nov 2014 Guessing minutes URL: http://www.w3.org/2014/11/14-aria-apg-minutes.html People with action items:[End of scribe.perl diagnostic output]