<Jemma> https://github.com/w3c/aria-practices/wiki/August-6%2C-2019-Meeting
<scribe> scribe: MarkMccarthy
mck: next meeting is next week,
Aug 13, things looking pretty open
... that agenda will likely be shaped by todays meeting. any
additions?
[silence]
mck: let's defer this until Jon is here
mck: we get a lot of feedback,
especially with naming and describing, that if we write about
new features as if they're ready and they don't work, that's
problematic
... most of the stuff in naming/describing is some of the most
mature parts of ARIA right now.
... if we add new information about the new roles and naming by
encapsulation, and if we do so in a way that doesn't warn the
reader these are -brand new- and may not be as robust, that
might be a problem
... we have said the one of the purposes of APG isn't to
measure levels of support, we don't want to put in a lot that
has to be modified later, but we've also never released a
dramatic version like this. so my sense is we need to do
something to warn people to new features. thoughts?
CurtBellew: do you then run into a problem where we have to say whats supported and not?
mck: yes, we want to avoid that. that's part of the aria-at project
jamesn: can we do something like a tag next to it, maybe saying aria 1.2, just to let people know when it was introduced?
mck: or like "new in aria 1.2", is that enough?
<jongund> prsent+ jongund
jamesn: a lot of it depends on
who's introducing the support. assuming we get the naming
mechanisms through the process, they're probably gonna be
supported almost immediately
... i don't foresee big problems with those, but things where
you expect AT to do something rather than an extension of
something already supported, that's a different level of
support
mck: our requirement is to user agent supported. say if Safari doesn't support it, we run into issues. we have issues like that with 1.1
jamesn: right - we have those problems today. telling someone when it's introduced gives a clue they should test more thoroughly
mck: right. but some readers
might not know the current version. if you're careful, you'll
see the dates at the top and links to latest, but it's probably
not super obvious to those new to aria
... i wonder if we should include a date somewhere else... but
then we might have to inject it somewhere so maybe not.
... if we have a section that's a mix of aria 1.1 and 1.2, it
seems like we should have something that calls out "new in aria
1.2" or describes it. do we remove it later?
jamesn: what i'd like is something like the p ref or s ref including the date when it's included, then we could remove it when no longer needed. if it's included by the spec generator, that'd be helpful
mck: yes, but it'd affect spec and apg
jamesn: i'm not averse to that,
need to discuss with joanie though
... maybe we could have a different script that runs on
spec
... either way, i'd like something that doesn't need editorial
work, just coding work. less chance to miss things
mck: we could put something in "read me first" section when we get to 1.3
jamesn: it could potentially just
note what version it was introduced in
... might be hard with screenreaders though
mck: i'm imagining hearing lots of punctuation
jamesn: yeah, that doesn't sound nice'
mck: but if it's something that only shows up in a section...
jamesn: ...yeah that might be okay
mck: is working on a script mod like that something you could take on jamesn?
jamesn: i could look at the
feasibility and maybe come up with a prototype
... someone else is welcome to help, sometimes the respec code
is a bit of a black hole though
mck: [bringing jongund up to speed]
jongund: there's some of all of that for aria 1.1 too right? [laughs]
mck: yeah, but that's kind of
water under the bridge now
... jamesn's main point was we don't want to do a lot of
editorial work, instead opting for programmatic solution
jongund: okay, got it
mck: i don't think i created an issue for this. I will and assign it to you james
jamesn: the idea would be to work out some coding magic. assign it to me, i'll take a look at it
mck: noted
... other comments?
[silence]
mck: we want to model what we
think would be the ideal combobox pattern (not the one
documented in any version of the APG) that Bryan and I think
will work the best
... with everything on the input, not using a wrapper. Jon, we
discussed some of this offline - have you made the changes we
previously discussed?
jongund: the rawgit link is
basically using the old pattern, but I can update it with all
the new things
... i updated it to conform to the documentation that was
modified for the [missed] button example, hoped to harmonize
it
... i made a lot of changes to it since last discussed to get
it ready for next release, but I didn't change the 1.1
implementation. that's pretty easy though, did you want me to
do that?
mck: yes
... my thinking is by the time we're at TPAC, i'm going to have
a PR for the ARIA spec with all proposed changes, with a
functional example - at least this one - to help people
understand what we're proposing
jongund: i can make those changes today
mck: i'm fine with changes being in this same PR
jongund: that's easier to do, sure
mck: let's do that then
... for now then, we don't have anything for anyone to look
at
jongund: one question - there was a discussion issue on disabled dates and behavior. do we want different behavior?
mck: we talked about that last
week, discussion was to not show those dates in the calendar.
so they'd be empty cells in the grid
... only show days in the current month
jongund: if you click or interact on those empty cells, they're inert?
mck: right
jongund: should it just be an outline of a date, so it maintains the look?
mck: this is a visual design question, so i'll defer
jamesn: well, lots of date
pickers don't have anything there. look at travel sites for
examples
... they use disabled dates for things you can't select
mck: we didn't do that in the past because we didn't have a use case
jongund: okay
... that's easy
mck: some code to figure out how many rows etc., but yeah should be pretty easy. easier than the other changes anyway
jongund: so we change that in the other example?
mck: yes please
... we have an issue open for it? did valerie raise it?
... [looking for issue]
... there is indeed no issue
<Jemma> https://github.com/w3c/aria-practices/commit/ecdb87a55dceed94ce0460bafc80d99c96757f3a
jongund: another question - would this example be under an aria 1.2 subdirectory?
mck: [laughs]
... let's just leave it for now
... ideally, we'll tweak everything so that there's only -one-
pattern
... i will propose to consolodate these examples, if ARIA WG
decides to move forward. whether or not that dream
happens...
jongund: that should be the goal, i agree
mck: whatever happens, we have some flexibility for now
mck: basically, what we've done
in the past is taking our prev milestone and shove everything
that's not done forward
... sort through those deferred, pick out most important, and
that forms next set of priorities
... 1.2 is a little different because it has to cover
everything new in 1.2, so those are a must
... beyond that, our next goal is comprehensive coverage of all
aria roles states and properties, prioirtizing widgets
... i don't have an easy way of telling what's missing
though
... i think it'd be helpful in this phase to have an easy way
to measure coverage
jongund: like a page called
Coverage or something like that?
... i had that originally, dont know if it made it through
though
mck: don't know it's somthing we'd want to publish as part of the documenet...
jongund: well yeah, we could link to it
mck: one thing we don't have
right now is an index to help point people to the right
place
... for instance, we have an example using aria-callcount but
not an index pointing people to it
... might be helpful to have what you suggested jongund, a
coverage status table, at least for the examples
jongund: what about for things we
-don't- have. could be a simple list right?
... or did you want something more statistical
... like how many examples of each?
mck: and thta could be 0, 1, 2, etc. that would be more useful
jongund: it could be sorted, or sortable, hmm..
<Jemma> https://github.com/w3c/aria-practices/wiki/Design-Patterns-Development-Status
mck: if it was in a CSV we could format it any way we want
<Jemma> This can be good info to start with.
jongund: Oh! okay, sure. then we don't have to link to it either
<Jemma> re: what we have in APG 1.1 if we update this.
I agree Jemma
mck: assuming we have other things fairly settled, are there things in aria that already exist which are important to be changed or fixed, rather than new items?
jongund: i'd like to work on something related to keyboard focus styling
mck: currently in the keyboard section, we do have some [not particularly helpful] information
jongund: yeah, and i'd like to go back and update some examples with current best practice techniques. like what we did with the toolbar
mck: we did that with accordian too, right?
jongund: not sure, but in any case they could be documented somewhere. i think there's a lot more we could provide guidance on for people wanting to do more than the minimum
mck: so i think maybe the bigger thing is how to prioritize what the community needs
jongund: i do think it's a prevalant problem. might some people think it's important? maybe not. but it's really common
<Jemma> Jon, are you referring to make this section be the better? https://w3c.github.io/aria-practices/#keyboard
CurtBellew: right, it is super common, visual styling is all over the place. I think this could be helpful
jongund: and our examples could benefit from providing some illustration
CurtBellew: right
jongund: and some other things need some minor updates anyway, so why not improve them with this anyway
mck: both what you're talking
about and issue 252 might work in a new guidance section or
something, and if the examples are updated, snippets can be
included. but then we have a referral section
... also where images can be included, and can link back to the
referral
jongund: that's a good idea
Jemma: i have a suggestion - why
don't mck and I update the design pattern dev status and come
back to find out what else we can add for aria 1.2, or make an
index
... this can help us see where we are and what really needs
doing
mck: yeah, that probably should
get updated anyway. information Jon will generate will help
with -coverage-, whereas what you mention Jemma will help us
focus on what's done and not
... just because we planned it in the past doesn't mean we
-have- to complete it
... another thing I want to do is clean up a lot of the open
issues, but I Want to make sure what we're working on is what
the TF thinks are most important
Jemma: Yup, gotcha
jongund: well i'll work on the coverage thing this week
mck: I Want to also work on making sure everything is collaborative as possible and everyone in the group think what we're doing is important, vs Jemma and I strongmanning
Jemma: right
mck: okay, so jemma and I will
update that page, Jon, you'll work on a coverage doc
... so I have to figure out how to backlog things or move them,
but I want to make sure everyone on the outside is clear
also
jongund: i did update the PR for tab carousel, I'd like to discuss soon
mck: so you want to get that in 1.2, okay!
jongund: yep
... I think APG will find this a valuable example and it got
tabled for 1.1, so yeah I'd like to get it in for 1.2
<Jemma> I will add tab carsousel to next week meeting agenda.
mck: one thing that tends to
happen near the end is scrambling to make sure tests are good
and editorial is done. i'd like to land things in master
sooner
... it's okay to work in parallel, but saving so many things
for the end can be troublesome
... i don't want to have to pull allnighters
[laughter]
jongund: right, and it's important to know what's happening. so maybe setting goals for each month and taking care of associated editorial work will be a good way to move forward
mck: that's not a bad idea
jongund: is valerie going to be available again in the future?
<Jemma> next week meeting agenda will include project priority selection from contact out work with Valerie
mck: i'm going to run some things
by her, such as accessible test outputs. it's hard for me to
see them sometimes and get info out. going to suggest using a
new output that can be converted to HTML
... which can be added to a PR and collapsed, similar to what
github bot for Zakim does
... it'd be nice to expand and read in line
... she has a proof of concept done, but it's a lot of work
jongund: I was hoping to get some time to go over how to write tests
mck: i was hoping for time too,
i'll talk to her. hoping to have her or someone similar
available at least one day a week all year to support us
... all right, i think we're good for today. thanks to
everyone!
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/liek/like/ Succeeded: s/tht/that/ Succeeded: s/oaky/okay/ Succeeded: s/plaec/place/ Present: Matt_King MarkMccarthy jamesn CurtBellew jongund Jemma Regrets: EvanYamanishi SarahHigley CarolynMacleod BryanGaravent Stefan Found Scribe: MarkMccarthy Inferring ScribeNick: MarkMccarthy 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]