<MarkMccarthy> scribe: MarkMccarthy
<Jemma> https://github.com/w3c/aria-practices/wiki/August-27%2C-2019-Meeting
<Jemma> Next meeting: September 3, No meeting on Sep 17 due to TPAC
mck: [reviewing agenda for the
day]
... we have this milestone for the third working draft to
include things for the fast approaching release of the
draft
... I want to make sure we stay focused and these are the most
important things we can be doing
mck: i merged a bunch of PRs,
JamesN had one that was merged two days ago
... review 1.2 IDL... I thought we talked abou thtis last week
- don't remember if we had a todo
... there's some implementation issues but not related to our
button. do we have anything left to do for this? i thought we
talked about this, does anyone remember?
group: [silence]
mck: don't see any comments
asking for changes to code, so...
... ready to close?
group: [silence]
jongund: not sure what this is about, what would we do with this example that'd be different than another button?
mck: just the way this is
written, so we have a way to test. main differences are in
JS
... looking at the example... it appears to be in the 1.2
branch, so it's merged
ZoeBijl: is this the normal
button example we're looking at?
... the role=button example?
mck: yeah, it's done using .role in the JS, that's the only thing that's different
jongund: so any role can be set that way
<scribe> scribe: link to this issue - https://github.com/w3c/aria-practices/issues/727
mck: we have made changes to the button example, ... it might be good to have some people look at this. i wonder if there's enough information on this page to go off of
carmacleod: we need info for other dot notation used
CurtBellew: the HTML source, shouldn't it reflect the JS?
mck: no, the source is the static source, so you won't see the button role as its set in the JS
jongund: it'll be harder to tell if it's accessible by looking at source, becuase lots is done in the JS
CurtBellew: I might be looking at
the wrong thing then...
... I see a div with tabindex...
jongund: all thta will be gone, you'll just see a div. the rest is added through JS
mck: this is interesting, so why is the role.button there?
carmacleod: we also used aria-pressed
mck: so maybe it wasn't declared using IDL?
siri_: if we're using this via JS and people are coming here and not seeing a role (if they can't see JS) they might be misled
mck: that's kind of the point of the ex. maybe we just used the idl interface for the pressed property? is that correct?
carmacleod: we used it to read the role but not to set it
ZoeBijl: can I ask why we're setting the role via JS instead?
jongund: because you can [laughs]
mck: in this particular example we're not, we're just reading the role of it, setting the pressed property
<carmacleod> https://rawgit.com/w3c/aria-practices/apg-1.2/examples/button/js/button_idl.js
ZoeBijl: i was wondering why though
<Jemma> https://rawgit.com/w3c/aria-practices/apg-1.2/examples/button/js/button_idl.js
mck: to illustrate the use of the
technique and to give a simple test, to find out if it works in
the particualr browser/AT combo you're using
... if you're building virtual components in avirutal DOM, this
is how it'll work
ZoeBijl: I agree, but I'll think about it - thanks
mck: strictly illustrative
ZoeBijl: aren't there better
examples though? like accordian maybe?
... I'm getting a little meta though...
mck: the idea was to do the
simplest possible thing to illustrate IDL
... might be a good idea for us to add more to the intro, maybe
like what carmacleod was saying
... if people comment or make a PR with enhancements that'd be
good
carmacleod: i can take a stab at a PR
<Jemma> role - button, state - ariaPressed in js
jongund: i think the example
should dynamically create the button. that might make for a
better example
... it'd illustrate a more dynamic behavior
... as is, it might be illustrating a poor pattern
ZoeBijl: that sounds more like a
technique than a design pattern. it's good! but maybe should be
separate
... if we're going that route, we'd have to change many
patterns
jongund: just saying maybe this one example could be better if it also did the above
mck: that makes sense to me
... this isn't a design pattern per se
siri_: a quick question, when talking about IDL, what's different?
jongund: it's just JS dom properties. you can now do that via JS rather than having to put it in the source
siri_: oh cool, thanks
jongund: like a shortcut using JS
mck: this is defined in ARIA 1.2, a new feature if you will
jamesn: it's not really quite
there yet, but it's useful where there's references to
something else, you can just ref the elems
... rather than having to find the IDs
jongund: that's future though, let's focus on the now
jamesn: yeah
mck: so carmacleod will do a PR
with some updates
... if someone could write something in the issue saying we
discussed
carmacleod: i did
mck: draft meter pattern, who had that?
<siri_> Can you give me some good website about IDL?
Sarah_Higley: that was me, i haven't gotten there yet
Jemma: me either
mck: looking for some time in
Sept if possible
... looking at colindex, that's me, and I don't think i can
make that for now
... now looking at insertion and deletion roles, there's'
output from discussion but i don't think we captured that. we
need to get this in
... jamesn, can you do a PR for this?
jamesn: yeah
mck: grouping in menu... right
now do we have a plan?
... issue 914
jongund: in our menubar example we have groups of controls
mck: we already do?
jongund: well we have the groups
of controls for fonts etc., checking it now
... we're already using group
carmacleod: that'd be great
jongund: yup, role=group for menuitem radios
<Jemma> https://github.com/w3c/aria-practices/issues/914
jongund: also for underline, colors, etc.
mck: oh the editor menubar!
... are these groups labelled jon?
jongund: yes, an aria-label
mck: so this is basically
done!
... adding that comment now
... i wonder if i should just close this then and refer to the
editor menubar
carmacleod: +1
mck: so that's good!
... and the listbox example, issue 913. that's also new in
1.2
... not sure that we have a listbox where grouping would make
sense at this point, might have to change the internals of
it
<Jemma> https://github.com/w3c/aria-practices/issues/913
mck: anyone have ideas for this that'd be a good way to illustrate this? something realistic?
group: [thinking]
Sarah_Higley: countries grouped by continents?
CurtBellew: time zones?
mck: a listbox to choose timezone... so states are ordered and grouped...
CurtBellew: yeah
ZoeBijl: i've seen OSs, versions of Windows or MacOS do that too
jamesn: that sounds better
carmacleod: or cities and timezones
mck: lots of data for timezones though
<Jemma> this was assigned to Sarah according to the issue.
mck: can be illustrative, doesn't have to be concrete
carmacleod: toronto and NY for eastern [laughs]
mck: it'd be good to see
something that we see in real life that makes sense
... normally a bunch of options, a visual separator, and more
options - is that how the visual presentation goes?
CurtBellew: sometimes more like a hierarchy
MarkMccarthy: I've seen both
mck: sounds more like a treeview that way, but maybe that'd work too
jamesn: can't we just use the example on MDN for optgroup that has dinosaurs?
<jamesn> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/optgroup
group: that'd be good [laughs]
mck: when they did that jamesn, does it have the visual labels for a group and some options?
jamesn: that's how optgroup works in a select
Sarah_Higley: that was my plan, to just pick some content and mirror the selects
jamesn: sometimes, more abstract is better
Sarah_Higley: got it [laughs]
jamesn: i just don't want to have to copy states and sort by timezones, that'd be a lot
Sarah_Higley: cats sorted by internet popularity
group: [laughs]
mck: really we just need like two
groups. i think we should just update an existing listbox, not
create a whole new example
... objections to that?
Jemma: I think jongund used to have the example for pizza toppings, maybe that's good?
mck: that's a tree
Jemma: oh ok
<jamesn> +1 to separate (but related) example
ZoeBijl: this could be a separate example because the HTML and JS will be more complex, more things to keep in mind
mck: okay, sold.
... Sarah_Higley, you were saying you could do this? is that
right?
Sarah_Higley: I did say I'd do it [laughs]
Jemma: i assigned Sarah_Higley a while ago, don't know why I did [laughs]
Sarah_Higley: I said i would! [laughs] it's all good
<jamesn> btw created https://github.com/w3c/aria-practices/pull/1140 for Insertion and Deletion
Sarah_Higley: remember end of sept being a reasonable timeframe, i can do that
group: [laughs]
mck: we have a nam and plan for every item here now, woohoo
mck: jon, can you give us a quick update?
jongund: sure. i'll put a link in
the chat [above]
... planned this for the last release. this is dfferent than
the others because they had next and prev buttons. many
carousels have dots indicating how many slides that are
clickable
... this example doesn't have buttons but it has six little
dots that are basically implemented as a tab pattern, can use
arrow keys to move between tabs, etc. just a variation of
another way to implement a carousel
... we have some live regions indicating when slides change
too
carmacleod: i think this is beautiful and it works really well. tried it with kbd and NVDA
mck: i see you put in some feedback about typos
carmacleod: yup and jon fixed them already
siri_: can we change the CSS for when buttons are not focused, it's difficult to see them if it's not focused
jongund: we've got the same features, two different view options. the second link moves the buttons off the image
carmacleod: i pasted that above
jongund: i think aria-current should be on there too
siri_: this looks really good, okay. thanks!
mck: so you fixed all the typos.. the checks are failing, do you know why?
jongund: not sure, haven't written tests yet. didn't think it had failures though
<Jemma> https://github.com/w3c/aria-practices/pull/1120/checks?check_run_id=204777760
jongund: some problem between regression tests, my test has no errors
mck: looking at the PR, that's where there are errors. maybe we just need to rerun the test
Jemma: there's a CSS linting
error and HTML linting error, meant to redo, haven't done it
yet
... pasted link of results above
... we can look into it in detail later
mck: i'd love to get this merged, we have carmacleod's review - more people can comment and provide reviews in the PR
mck: we've got the heavy duty
discussion here, this is just follow up closing the issue
... we all agreed that the esc behavior should be optional and
only if combobox is already cleared
... so i made a minimal change
<Jemma> one of html build error is "tr is starting of table body"
<mck> new wording: • New wording: Escape : Dismisses the popup if it is visible. Optionally, if the popup is hidden before Escape is pressed, clears the textbox.
mck: making sure before merging, is this wording clear?
carmacleod: looks good to me
ZoeBijl: this is saying that if focus is on the combobox and you press esc, anything you did put in is cleared?
mck: yes, optionally
<Jemma> https://github.com/w3c/aria-practices/pull/1129
<siri_> can you paste the link ?
carmacleod: only if the list isn't showing
ZoeBijl: wouldn't it make sense to just remove focus?
<Jemma> "Makes clearing textbox optional, an only if the popup is not displayed."
mck: that's a different behavior not related to the combobox, depends on context of the combobox, haven't seen it many places on the web
carmacleod: maybe a dialog
mck: i think this is a behavior we'd say is part of the combobox
ZoeBijl: but because we're overriding what they key does I was just curious
Sarah_Higley: I don't think i've seen esc move focus out of a control that's conditionally available
ZoeBijl: that's what I meant, say i'm in a form and i'm in an input field, esc would just take my focus out of that
mck: that'd be undesirable for me
carmacleod: where would focus go?
ZoeBijl: i'll have to look into it
mck: ZoeBijl is it okay if we merge this and you can add updates later?
ZoeBijl: yeah no problem, i'll come back to it if I find issues
siri_: so when you press esc, where does focus go? to next focusable or...?
mck: focus doesn't move, this
bullet doesn't mention moving focus
... this is -only- talking about clearing text
siri_: but the next question is where focus goes
carmacleod: on the textbox in the combobox
mck: yeah, that's already
addressed in the pattern
... the whole pattern is linked in the agenda
siri_: okay, thank you
mck: jon gave us this, it's awesome. you have updates jon?
jongund: i added more references
to guidance sections, added headings, if the headings mentioned
a role or property, you could also add a data-attribute
... ... to a heading, so everything is tied to the
heading
... if there's a heading you want related to a certain role or
property, there's a data-aria-props and other related things
that the script looks for
... everything's on a heading
... now it's generating I think 6 groupings - roles w/o
guidance or examples, roles with one, roles with more than
one,
<Jemma> Roles with no Guidance or Examples / Roles with at Least One Guidance or Example /Roles with More than One Guidance or Example /Properties and States with no Examples Properties and/ States with One Examples Properties and States with More than One Example
Thanks Jemma
mck: i think the main thing I want us to discuss is the approach of having the data attrs on the headings
<jongund> https://github.com/w3c/aria-practices/pull/1124
mck: we have to think long term, my question being how much does it matter what the names are? i'm fine with them as is now, but asking for other feedback
carmacleod: can this info be generated automatically without the data-attrs?
mck: if you use a code tag in a heading...
jongund: well it doesn't look at code tags, if you just look for that property or role... it's just looking for a string match
mck: you excluded section 3 then,
right?
... the examples section? with ID=aria_x
jongund: I don't think so, I think we have references
mck: i'll look into this a little closer
Jemma: what do you mean by ID?
mck: i was talking about the ID
we exclude, it's aria_x or x_aria, something like that
... i'll look at everything
jongund: you could use the data attr if it's an issue
mck: thinking of how to augment our indexing with this... it'd be a good way to get info about roles, guidance, and patterns. not as part of this PR
jongund: this is internal
mck: other thoughts on the data attributes being rolled into the master? with these names? data-aria-roles and data-aria-props?
carmacleod: i foresee potential
maintainence issues
... can't we just scrape the table? or is that too much?
jongund: just looks for headings,
then for the text inside the headings, ignores other things on
the page
... for the examples, it goes into the tables. for guidance, it
just looks at aria practices HTML doc headings
mck: we can do the same thing for
patterns which we've done for examples
... we just don't have a standard format right now
... that might be another source of information though that has
some robust info
jongund: i guess keeping track of
the last heading, using the heading before it for
reference
... i don't think all the headings have IDs
mck: right. we have an issue with respec where adding IDs to headings in sections below a label - if they have notalk on them, it scrapes away IDs
Jemma: i think this is good enough as a first draft, why don't we keep this as is and start work on another version
mck: i just wanted to get some feedback on this right now
jongund: another approach would
be to keep track of the most recent ID
... then you wouldn't need data attrs
... i like carmacleod's idea, less maintainence
mck: the more we can automate the better. there are sections we might want to point to where we don't mention stuff in the heading...
jongund: well after the heading, it'd just look in the content for relevant info, after the last referenced heading
mck: doesn't tell us whether or not we've covered a certain thing though. ther's some things where we have lots of mentions without describing issues etc.
jongund: that's true, you'll get a lot more things that aren't so relevant
mck: or useful
... so do we want an index that sends you everywhere
or...
... for this, i just wanted to find gaps etc..
jongund: maybe data attrs are
better
... if it's not mentioned in the heading, maybe it's not a good
reference
carmacleod: +1
mck: right
carmacleod: we just have to note that we might need to modify the data attrs
mck: we might be able to do some checking for stuff like that, similar to what Valerie has done for regression test reports
carmacleod: that's a good idea
mck: thanks everyone! good work today.
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/anyon/anyone/ Succeeded: s/fifferent/different/ Succeeded: s/+!/+1/ Succeeded: s/howing/showing/ Succeeded: s/thankyou/thank you/ Succeeded: s/estc/etc./ Succeeded: s/reprots/reports/ Present: Jemma Matt_King MarkMccarthy jongund Sarah_Higley carmacleod CurtBellew ZoeBijl Siri Found Scribe: MarkMccarthy Inferring ScribeNick: MarkMccarthy Found Scribe: link to this issue - https://github.com/w3c/aria-practices/issues/727 Scribes: MarkMccarthy, link to this issue - https://github.com/w3c/aria-practices/issues/727 Agenda: https://github.com/w3c/aria-practices/wiki/August-27%2C-2019-Meeting WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]