See also: IRC log
<scribe> scribe: jamesnurthen
MK: Start at the top of the list. Walk through and work out what we are going to discuss
<sirib> https://mit.webex.com/mit/j.php?MTID=m4b54b847795d432ef8a2ba82e488fea2
https://github.com/w3c/aria-practices/issues/321
MK: will look at this with Tatiana.
https://github.com/w3c/aria-practices/issues/334
MK: assume this is still outstanding
<jemma> mak logs public
<jemma> make logs publick
<jemma> make logs public
https://github.com/w3c/aria-practices/issues/144
MK: have to merge - there is a PR related
https://github.com/w3c/aria-practices/pull/340
merged the new PR into it
MK: will do final checks on 340 - feedback has been addressed
Logged https://github.com/w3c/aria-practices/issues/355
MK: 1 thing we dont have in menu examples is an example of using aria-owns rather than putting the children inside the menu item
<jemma> arrow keyboard navigation in vertical menubar will be reverse of horizontal menubar's
MK: vertical menubar priority is relatively low
https://github.com/w3c/aria-practices/issues/325
http://w3c.github.io/aria-practices/#dialog_modal
<sirib> is it 325?
yes 325
<jemma> +q
bryan: dont understand its purpose if it is not to hide the content from at users
When a modal element is displayed, authors must ensure the interface can be controlled using only descendants of the modal element. In other words, if a modal dialog has a close button, the button should be a descendant of the dialog. When a modal element is displayed, authors should mark all other contents as inert (such as "inert subtrees" in HTML) if the ability to do so exists in the host language.
(from the spec)
MK: it is a screen reader's job
to limit navigation to stuff inside a modal
... what makes something inert is the real issue
seems to me that is a screen reader user can see what is outside the dialog - it is still the author's job to ensure that activating links outside the dialog doesn't do anything.
MK: if you can see and operate outside the dialog should not be using aria-modal
JN: will work on it
When a modal element is displayed, authors must ensure the interface can be controlled using only descendants of the modal element. In other words, if a modal dialog has a close button, the button should be a descendant of the dialog. When a modal element is displayed, authors should mark all other contents as inert (such as "inert subtrees" in HTML) if the ability to do so exists in the host language.
https://github.com/w3c/aria-practices/issues/279
MK: gave Feedback in the
issue
... ready to close
https://github.com/w3c/aria-practices/issues/224
<discussion on change>
<sirib> It is little confusing
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Present: AnnAbbott jamesnurthen Bryan Garaventa matt_king Shirisha Balusani JaEunJemmaKu Found Scribe: jamesnurthen Inferring ScribeNick: jamesnurthen WARNING: No "Topic:" lines found. WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 10 Apr 2017 Guessing minutes URL: http://www.w3.org/2017/04/10-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]