W3C

- DRAFT -

ARIA Authoring Practices

14 Nov 2014

Agenda

See also: IRC log

Attendees

Present
+1.217.244.aaaa, +1.650.738.aabb, Matt_King, James_Nurthen, LJWatson, Bryan_Garaventa, Jemma_Ku, Michael_Cooper
Regrets
Chair
Matt_King
Scribe
jamesn

Contents


<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

Link Example

<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

Future meetings

Will not meet Nov 28, Dec 26 or Jan 2

<kooje> ok

<mattking> http://www.w3.org/WAI/PF/aria-practices/#checkbox

Checkbox

MK: this is what got us into the keyboard handling part

button

<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

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2014-11-14 18:51:08 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]