See also: IRC log
<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[End of scribe.perl diagnostic output]