<jongund> present* jongund

<jamesn> For comparison, re-aranged but unedited content is in branch https://rawgit.com/w3c/aria-practices/keyboardSection/aria-practices.html

<jamesn> For comparison, re-aranged but unedited content is in branch https://rawgit.com/w3c/aria-practices/keyboardSection/aria-practices.html

<mck> take up first item

<scribe> scribe: Birkir

<jamesn> next item

JG: Did not get much guidance on the math role, other than what is in the existing APG

<jongund> https://www.w3.org/TR/wai-aria/roles#math

JG: Math is still a bit of an art on the web, Mathjax is the best we got. Mathml support is not going to be implemented widely by browsers.
... Latest rumours say that SVG rendering combined with Mathjax might be what people end up using.

MK: the math role is not a widget role, it is a structure role, similar to section.
... I am wondering whether there is a place for the math role in APG, at least at this time, given the inconsistent and unclear support.
... the word "Hook" in the ARIA spec is misleading, it is not an API call. The content of the math section itself should be all the a.t. needs to interpret it.

BG: Since there is no mechanism for exposing math, and since we don't want to copy the text of the ARIA spec, it might be best to remove the math entry from the APG at this time.

JG: what if we have an image with a mathematical expression, would the math role be appropriate for that scenario?

Consensus: w want to know that an equation in an image is part of an image, so mapping the image as a math role might not work.

MK: TAke on action. Communicate to Rich that the APG has nothing to add to the math role as described in the ARIA 1.1 standard. If he disagrees, can he point us to resources to enhance the guidance we can provide in the APG math entry.

JN: Figure out the source of the comment on the math section (referencing comment 4).

MK: JN, can you take on that action.
... (in response to AA) We could revisit APG scope, but not today.

JG: I will contact Neil Soiffer and see if he has something to add.

MK: This is a link to my keyboard section hackfest branch.
... Took keyboard section in existing APG, by merging content from primar and original APG 1.0.
... I set them aside, dug up nuggets from both and rewrote a brand new keyboard section from scratch.

AA: Where do I find this section?

<jemma_> https://rawgit.com/w3c/aria-practices/keyboardSectionHackFest/aria-practices.html#kbd_generalnav

MK: Try "section 5".

Jemma: I reposted the link in the chat.

MK: Want us to review sections 5 and 8 today, apprecaite feedback from people after the call with the goal of merging the section in master before Thursday's call.

<jemma_> https://rawgit.com/w3c/aria-practices/keyboardSectionHackFest/aria-practices.html#keyboard

AA: Denotes an amusing typo in the spec .. but what it was shall remain privelleged info only for those who attended the call.

JG: Can we use the landmark article general structure, such as including steps for building keyboard interface.

MK: A little hesitant to do that.

JG: your desired keyboard interaction model might dictate the ARIA roles used.

MK: Good idea, but it would be better to put that in a separate section.
... IF we intergate the steps into this section, the steps might get buried.

AA: Concerned with the million and 4 links in the section .. people might find it too hard.

JN: Bu it is hard. ;)

MK: People are most likely to go to the section describing the widget they need. Those sections should ahve all the relevant keyboard function guidance they need.

JN: Need to do a more thorough review.
... Points to language in section 5.1 that needs langauge adjustment.

MK/JN: Discussions about requirement that all functionality on page needs to be operable without a keyboard shortcut. While true for consumer facing web applications, it might not hold true for web apps where efficiency trumps discoverability.

<MichielBijl> I think WebEx froze?

MK: If al users need to read guidance this applies. But if mouse users can operate app without reading a manual, this does not apply.
... WE try to avoid any normative language here.
... As you review spec, make sure to soften up normative sounding language.
... Moving on to esction 5.8 (keyboard shortcuts). It took hours and hours.
... Is first paragraph soft enough?

JG: How about dropping the unnecessary language such as "effective designed".
... Concentrate on what people might want to use keyboard shortcuts for.

MK: Language is purposeful, politely saying people could screw this up real bad.

JG: are up and down arrow keys in a combobox keyboard shortcuts?

MK: No, but alt-f10 to move to the toolbar would be.
... Keyboard shortcut should always be associated with an element, could be associated with an element currently not visible.
... Move on to section the section on "conflicts".
... The goal with this section is to help remove keyboard shortcut guidance from the normative ARIA sepc.

JG: Due appreciation for the work done here, it ain't easy.

MK: Do people agree with the secope of the language in section 5.8?

Birkir: Need to read more carefuly, but like the scope and language.

MK: Got content down to 3 bullet (note from scribe, I think these are 9mm bullets, they sure pack a punch).
... Bullet one, avoid modifier keys with space enter, escape etc. (bulet one).

AA/MK: REviewing minor editorial and spelling changes.

MK: Looking for input on operating system key conflict, both more keys and more specific information.

JN: Too much detail, we need to stay clear of those, too many differences between operating systems and versions.

MK: Last section plans to introduce the "reasonably save" key combinations, section still remains to be written.

JG: WE got too many "don't do", sections.

Group discussion, perhaps put things you can do before things you shouldn't do.

AA: What about section 5.8.2.4 9mitigating conflictnad impact).

MK: I am working on this section. Using examples of localized keyboard shortcuts (those that only work with focus on a control such as a listbox).
... 26. (of May) is the deadline for providing something.

<jemma_> who is here?

WE identified the phone intruder .. Bryan ... we do not have an assigned bouncer so we had to let him stay.

MK: AA and JGs section on landmarks obliterated section 7.

AA: Recommend removing anything regarding landmarks from section 7.

GRoup: Everything written in section 7 regarding application role is no longer accurate (after application role text was rewritten).

MK: Remove section 7.1 and 7.2 in the branch whose URL was posted above (content in this branch has gone through significant rearranging).

AA: Also get rid of section makred "7."

MK: Thanks everybody. If you ahve specific feedback, please provide to me in the next couple of days.

<jamesn> NO MEETING NEXT WEEK

MK: No meeting next week (Memorial Day).

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Birkir
Inferring ScribeNick: Birkir

WARNING: No "Topic:" lines found.

Present: JamesNurthen AnnAbbott matt_king jaeunjemmku jongund MichielBijl

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

Got date from IRC log name: 23 May 2016
Guessing minutes URL: http://www.w3.org/2016/05/23-aria-apg-minutes.html
People with action items: 

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


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report