See also: IRC log
<trackbot> Date: 12 October 2015
<scribe> Meeting: ARIA APG TF
<JemmaKu> + jemmaku
<JemmaKu> https://cdn.rawgit.com/a11ydoer/practices/master/examples/checkbox/checkbox-1.html
Discuss status of example development.
2 template examples:
https://cdn.rawgit.com/a11ydoer/practices/master/examples/coding-template/template2.html
<JemmaKu> https://cdn.rawgit.com/a11ydoer/practices/master/examples/checkbox/checkbox-3.html
<scribe> scribe: jamesn
MK: no changes
... working on menu right now but didn't finish it
... last week we left the conversation - we are not done with
that
<JemmaKu> me/waves hello to Michiel
MK: was looking for another bug on the menu pattern - 1 is out of order
jn: I will submit the other bug
<JemmaKu> https://cdn.rawgit.com/a11ydoer/practices/master/examples/checkbox/checkbox-1.html
<JemmaKu> https://cdn.rawgit.com/a11ydoer/practices/master/examples/checkbox/checkbox-3.html
JN: space doesn't seem to toggle the all condiments checkbox
JK: can look into fixing
MB: why are we using divs rather
than checkboxes
... i think we should encourage people to use the native
element
JG: If i am building a checkbox
out of SVG then you don't have them
... you are not suggesting having a role on a checkbox are
you?
MB: no
... suggesting having a mix of html checkboxes and aria
checkboxed like i did with buttons
JG: waht is the advantage of that
MK: if using a native checkbox
you don't need any aria at all
... I guess that is true of button too
... could make a toggle button or a menu button out of an html
button
MB: we should encourage people to use native elements if they can
MK: if you were using actual checkboxes what would you use aria for
MB: in my view we should show both sidesa
JG: could put a note in it
<MichielBijl> Note: When using HTML use the <button> element. It is recommended that authors not re-purpose other elements to create buttons.
MK: we put comething like that in link
JG: could add some standard ones
to the mixed example
... in this case standard checkboxes are used and role=checkbox
was used on the mixed one
MK: we would end up putting that note in everything that has an HTML equivalent
JG: would make examples more complex if have to explain why there are mixes of things
BG: see a lot of devs that put
role=checkbox on checkboxes
... when aria checkboxes are handy is on touchscreen. People
make checkboxes where the only thing visible is the label, but
there is no visible checkbox there
... on desktop can use off-screen standard checkbox. on mobile
that doesn't work so well
MB: we encourage people to use native elements.
JG: we are not trying to teach people how to use a standard checkbox. there are other places for that
MK: thinking a little about the
points steve makes in using aria in html docs
... it is the aria authoring practices guide
... we do want to help people using aria in html do so
correctly
... you are starting to sway me Jon. Because there are places
that there is redundancy in aria.
... if put <main> role=main is still enouraged in some
places
... i don't know if that is still a good idea
MB: i view it as a place to send devs to learn how to do a design pattern
MK: we are trying to cover the aria roles
JG: we should do the roles we
want people to use
... the main thing of documenting the patterns with an example
for each role. Then see if have bandwidth to work on
ant-patterns
MK: already have a plan for which
ones we are going to do
... i don't think we need a plain html checkbox example, but a
note would be good
... in the notes column - could add a note that "role checkbox
is not applied to the standard checkboxed but is to the aria
checkbox"
BG: could be useful to note which
roles have implicit native semantics
... there are others which do not have native semantics
MK: i wonder if we should
incorporate the implicit semantic language into this document
someplace
... either do this or refer to it in steves document
... Jon if you can do the 3rd example that way for the mixed
checkbox and add the note as described
IP: role presentation doesn't
make an attribute optional
... aria-describedby attriebutes don't have an element with
that ID
http://www.w3.org/TR/WCAG20-TECHS/F38.html
role=presentation doesn't allow you to skip alt="" according to the html validator
JN: WCAG allows it
MK: I want to get the language
about implicit semantics into the APG in appropriate
places
... dont know yet if it would be good to have a section about
implicit semantics and reference it or come up with a short
phrase
LW: once is easiest
+1
LW: can also link to the mapping
documents from that explanation
... i think it is worth taking a handful of sentences to
expalin it
JG: checbox 2 will reference aria-describedby for a grouping element
the aria-describedby will say what group the checkbox belongs to
https://cdn.rawgit.com/a11ydoer/practices/master/examples/coding-template/template2.html
<JemmaKu> https://cdn.rawgit.com/a11ydoer/practices/master/examples/coding-template/template2.html
<JemmaKu> thanks, James
MK: MB also brought this up
JG: the basic compoennts of bothe templates is the same
JK: let me copy the new link for template 3
MB: I would go for the checkbox example as I dont like tables
JN: tells people what is implemented and what isn't
MK: tells people which decisions are made and what aren't
JG: if we can reinforce things it is good
AA: i agree with Jon
<JemmaKu> I fixed the coding.
<JemmaKu> https://cdn.rawgit.com/a11ydoer/practices/master/examples/coding-template/template3.html
MB: should add a line which states that this is the support for this implementaiton
MK: on the checkbox example page
there is a heading of simple checkbox
... right under there is coding exmample heading
JG: checknbox 1 simple checkbox -
there would be no special name other than coding exmaple
... or would we assume that right after h1 the coding example
would start'
MK: these are rendered checkboxes
so coding example is confusing
... i dont think we need 2 H1s
JG: thinking about SEO putting stuff in the banner would help
MK: H1 in the banner is fine but
next in the page should be an H2 - simple checkbox
example
... dont know if we always want to number the examples -
perhaps name them
JG: checkbox role: simple checkbox
MK: prefer checkbox pattern: simple checkboix
LW: where we have variants perhaps keep 1 per page and then have related patterns
MK: we have the cell in the table where we have examples
LW: also perhaps have related patterns linking to the other
MK: 1 pattern per page
JN: sounds like editorial
work
... to add links if we decide we want them
JG: assumed that the example would start after the h1?
MK: fine to have an H2 after it before the example
JK: just an h1 in the main content - don't need a banner
JG: H1 will include checkbox pattern to mark the start of the example?
MK: wanted to put the code in the ewxamples on the agenda?
MB: want to look at the
descrtiption in the checkbox example
... is there a name for this style of comments
JK: working on refactoring and
the comments
... using jsdoc
MB: like we are using 2 spaces instead of tabs. a bit more compact
IP: commetns about js style
... I think argument for 4 spaced tabs as more commonly used
and would make it easier to copy into wider sodebases
... variables that are global which we need to avoid
... all the functions are global which we need to avoid
... I would suggest we stick with semi-colons rather than not
using semi-colons
... it will work but you need to understand the rules and not
many who say they do actually do
MK: a lot of devs don't understand when it is ok to skip semi-colons so better to have everywhere
IP: reduces cognitive load
... I don't get the argument that it makes your file larger is
a good one
+1
IP: in the case of groupboxstate = .... changed to lower case , should set the true or false, but there is a convention of creating a variable with values in upercase and then compare against your "constant" when setting and getting
<LJWatson> +1 to using ;
JK: should i submit code revioew to github and that would be the best way
IP: as we decide need to document them
<LJWatson> +1 to code reviews (friendly ones :)
MK: the purpose of it being on
the agenda is to decide the conventions we wantr to have
... if we are going to have them then need to document them
<MichielBijl> Link to git issue: https://github.com/w3c/aria/issues/95
MK: are we going to have a long list of things
IP: can link to existing
standarrds
... must pass a jshint lint test with certain settings
... github has their own standards etc.
... would be my approach to link out to things
... using jsdoc is a good decision
... if keep it very simple then can use external tools
MB: I have a csscomb file for
everything i create
... for css files
IP: do we have anything on the
wiki for how to contribute
... if so it should be there
MK: need exactly what you are
saying on the wiki
... trying to go to the participation pages
<JemmaKu> I like git issue Michiel created. This would be very helpful for coding sinceI am not js developer yet
MK: seems like a michael thing that stuff in the pf pages are very out of date
LW: problem i found with github is that our work was in the main repo
<JemmaKu> having some standard coding practice doc would be very helpful.
LW: it still may be possible but need to work out how not to get in other peoples way
<JemmaKu> question to Ian
<JemmaKu> +q
MK: a page on how to contribute would be very useful
LW: more complex than it ought to be as we have multiple lines of work in the same repo
JN: should bring this up on the editors call
MB: before meeting ends
... was working on the alert example - when I started on the
code example
... wanted to share the progress
<MichielBijl> http://s.codepen.io/Michiel/debug/0f9ce27964f35b55d3e7628d91874c2e.js
<MichielBijl> http://s.codepen.io/Michiel/debug/0f9ce27964f35b55d3e7628d91874c2e
MB: wanted some feedback
... no way to get a list of focusable elements...
... there is no way to get an array of focusable elements
... wondering if someone had a more reliable way of doing
it
... jqueryui guys do it the same way
IP: dont think there is a native way
MB: the way I do it doesn't work.
<JemmaKu> https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelectorAll
IP: does it in the order of your
selector
... rather than write the script so it focuses on the first or
last. could put a selector in a data attribute and then set
focus to that
MK: should read the describedby
so long as anything in the dialog gets focus
... the author can specify which element should get focus when
it opens
IP: the things which read out a long describedby and then the element with focus. is this something you want to hear? or would you prefer to get a tab press first
MK: jaws will read the
description last
... others may do it differently....title then description and
then focused element
... always easy to do VO-F3 etc to find where the focus is
IP: you are happy with that
... I would set focus on the container
MK: I think it should always go to the first piece of content
BG: as far as screen reader behaviour goes. aria-describedby should only be annunced once in the dialog but Ie11 w/ JAWS is announcing it on each tab press
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/default file/csscomb file/ Found Scribe: jamesn Inferring ScribeNick: jamesn Present: (no one) JamesNurthen JemmaKu jongund AnnAbbott MattKing Raghu Michiel_Bijl IanPouncey Bryan_Garaventa LJWatson WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 12 Oct 2015 Guessing minutes URL: http://www.w3.org/2015/10/12-aria-apg-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]