<trackbot> Date: 18 May 2015

<kooje> hi

<annabbott> Hi All! I get busy signal trying to dial in

<jamesn> should be +1-617-324-0000,,,646444732#

<annabbott> US toll call-in: +1-617-324-0000

<annabbott> Access code (meeting number):646 444 732

<jamesn> i recommend trying again

<annabbott> but I never get to the Access code

<jamesn> i have heard that sometimes it takes dialing a few times

<annabbott> third time = busy signal again

<jamesn> hmmm

<jamesn> i can dial you

<jamesn> ping me your number in IRC

<annabbott> 512-286-3003

<kooje> I cannot hear anything

<kooje> that is me.

<kooje> I am calling it again since I cannot hear anything

@kooje you need to join using WebX, not the old phone. Do you have the agenda email from Matt? It includes the WebX link/info.

<jamesn> Jemma - we are on webex - +1-617-324-0000,,,646444732#

Or online here: https://mit.webex.com/mit/j.php?MTID=m71a4dbc9d1dd947b1ad8eecfa8f1d0ff

<jamesn> Jemma - seems we have dial in issues. Can you use the web client?

<kooje> I am in. I used web client to join

Ann to recap... in the WebX app you should be able to get it to call a phone number you provide.

<jongund> Hello

Example Format for including the source

LJWatson: scribe

<jongund> http://jongund.github.io/aria-examples/slider/slider-1.html

JG: Updated slider 1 and 2 examples, based on feedback from last week.

<annabbott> Clicking on Jon's link just closed the WebEx meeting, but I'm still hearing the call.

@Anne the app will still be running, it's ok to close the browser window.

<annabbott> Yes, but I can no longer mute/unmute

JG: Have added source code highlighting.

MK: Don't think people will understand the brackets.
... Perhaps take brackets out?

JN: I like the way it is.

MK: But don't understand the brackets...

JN: It's where something isn't a literal.

IP: Looks like they're tokens?

JG: Yes.

IP: Perhaps a glossary of expected tokens would be a good idea?

+1 to token glossary.

MK: Could communicate same information in a way that is easier to interpret? To me as a s/reader user at least.

JG: Another approach would be to use styling to indicate accessible name, not brackets.

JN: But a screen reader user would lose that information.

BG It's difficult with a braille display too.

JG: Does adding "value" add anything?

MK: Not really.

BG: What about adding a column...

MK: Nice idea, but more work.

<annabbott> Is there still discussion ongoing - I can hear nothing. WebEx indicates I'm still connected.

<annabbott> Audio just resumed

LW: Why don't we use the accessible names etc. from the example in question?

BG: Like the idea of exact verbiage.

JG: We could be more specific.

MK: It might slow down example development, but we have to think about what our readers will benefit from.

JG: So the results column should be more realistic?

BG: I'll take an action to write out what I'm suggesting...

JG: Thanks.

JN: This table represents more AT than most people have.
... If we provide a subset, hopefully people will contribute results for other ATs and/or file issues if there are errors.

LW: We knew the risk of including AT results would be turning it into bug identification.

MK: Yes, we want to reference behaviours for some AT though.

JN: I'm in favour of only including the latest AT version tested with, even if it shows a poorer result than an older version.

LW: Agreed.

MK: One result per AT/browser combo?

JN: Yes.
... Should we include a note... if you find these results incorrect, please go here to fix code and/or fle issues/provide updated info.

IP: Suggest we de-couple this... include one/two patterns, then consider support differently/spearately.

MK: It might be unusual that so many AT/browser combinations behave similarly.

IP: But is it significant for a developer to know what the exact differences are?

AA: I think it's important to provide expected result, then specific results.

MK: No, we're not providing expected results.

AA: Could say it should announce acc name, role etc.

MK: That's outside the remit of this TF, and the ARIA TF in general - telling UAs how to present information.

JG: I'll take out redundant ATs.

<scribe> ACTION: Birkir to write up suggestions for making AT test results in ARIA APG examples more readable. [recorded in http://www.w3.org/2015/05/18-aria-apg-minutes.html#action01]

<trackbot> Created ACTION-1636 - Write up suggestions for making at test results in aria apg examples more readable. [on Birkir Gunnarsson - due 2015-05-25].

LW: Really feel strongly we shouldn't include browser/AT specific bugs/issues/information.

IP: Agree.

JN: With Jaws pushing out two releases in the last couple of weeks, this information is going to be out of date too quickly.

LW: Yes, so it'll be out of date, and I don't believe of help to developers. We should just be recommending best practice.

IP: Simple example... if I have a heading, I don't care how a screen reader reades it, it's useful to know, but it doesn't make any difference to the fact I should be using a heading.

<annabbott> Ann has to leave call now

JG: We still don't seem to have consensus. Will take a look at these sections.
... Will take them out for now.

rrsagent make minutes

Proposal for next 8 design patterns to target for July 30 heart beat publication (Matt)

Timeline for Hearbeat Publication

Things are in motion with the PF charter, but thinking about a heartbeat sometime in July sounds about right.

MK: So when we get closer to July, we'll need to assess whether the edits we've made will make it worth publishing a heartbeat. I think that's likely.

JS: Compartmentalising might also be an option.

MK: Ok, we'll see how it goes.

Proposal for next 8 design patterns to target for July 30 heart beat publication (Matt)

<mattking> In the 14 May 2015 public working draft, edits to guidance for the following patterns were completed:

<mattking> * link

<mattking> * button

<mattking> * checkbox

<mattking> * radiobutton

<mattking> * menu

<mattking> * popupmenu (removed)

<mattking> * spinbutton

<mattking> * slider

<mattking> * slider two thumb

<mattking> * alert

<mattking> * tooltip

<mattking> * windowsplitter

MK: These are the ones with completed guidance, but they need examples for most.

<mattking> Proposed target for guidance edits to be complete by 30 July 2015 for next heartbeat:

<mattking> * menubutton

<mattking> * Listbox

<mattking> * autocomplete

<mattking> * combobox

<mattking> * TreeView

<mattking> * toolbar

<mattking> * dialog_modal

<mattking> * alertdialog

<mattking> * dialog_tooltip

<mattking> * popup help

<mattking> * dialog_nonmodal

MK: We have a couple of bugs logged against menu button, but they seem ambiguous. Should revist.
... Also should revisit listbox.
... Started talking about autocomplete, but didn't file any issues. Proposal is to tackle these next week.
... Week after, treeview, modal dialogues, plus flavours of dialogues.
... Might get all done for the heartbeat...
... After that we get into composites like toolbar etc.

+1 on tight meetings.

JN: Sounds good. Need to make sure we stay focused in meetings if we plan to get that done though. Not like today.

BG: We should move accordion up.

MK: Initial plan was to do fundamental widgets first, but we can move accordion up...

BG: Put it as first of composites.

Listbox pattern review https://rawgit.com/w3c/aria/master/practices/aria-practices.html#Listbox

MK: Added text about static behaviour.

JN: There is a third type of multiselect lstbox... where you visually select an option and it appears like a bubble in the field, and you click next to move to the next option. Do we want to cover this?

MK: Difference is the checkbox toggle becomes an x toggle in the bubble.

JN: You select/unselect in a different way though.

MK: Think it's a different pattern.

JN: Ok.

MK: Added paragraph about option names, based on my own experience.

JN: We're trying to provide something that extends default browser behaviour here.

BG: Wonder if for the complex ones, we should split keyboard support into basic/essential, and advanced/good to have?

JN: Think we've done that in some cases?

BG: Think it would reduce the shock for developers.
... I'm a confident computer user, and I've never come across many of these key shortcuts.

+1 to not coming across many recommended shortcuts.

MK: Have a question about handling focus in a multi-select listbox... The bullets where it says when a listbox receives focus... think the second bullet is debatable.
... If you back tab to the listbox, it would go to the last item that had focused. Wasn't sure that was desireable, or standards behaviour.

JN: Sounds like the radio group discussion?

MK: So leave it as is?

JN: Yes.

BG: There are problems with the visible focus indicator on multi-select listboxes I think.
... I'm blind, so not sure of details...

JN: Yes, definite problems between knowing whether something is selected, focused, or both.

MK: There are patterns where we have notes about visual design... we could persist in that practice?

BG: Yes in this case, advice about selected versus focused would be good.

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)

Succeeded: s/Meeting: Protocols and Formats Working Group Teleconference/Meeting: APG Task Force/
Succeeded: s/BK:/BG/
No ScribeNick specified.  Guessing ScribeNick: LJWatson
Inferring Scribes: LJWatson
Default Present: +1.217.244.aaaa
Present: +1.217.244.aaaa Janina LJWatson Matt King Birkir Ian Pouncey James Nurthen Ann Abbot

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 18 May 2015
Guessing minutes URL: http://www.w3.org/2015/05/18-aria-apg-minutes.html
People with action items: birkir

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.