W3C

- DRAFT -

August 6, 2019 Authoring Practices Telecon

06 Aug 2019

Attendees

Present
Matt_King, MarkMccarthy, jamesn, CurtBellew, jongund, Jemma
Regrets
EvanYamanishi, SarahHigley, CarolynMacleod, BryanGaravent, Stefan
Chair
Matt King
Scribe
MarkMccarthy

Contents


<Jemma> https://github.com/w3c/aria-practices/wiki/August-6%2C-2019-Meeting

<scribe> scribe: MarkMccarthy

Future meetings

mck: next meeting is next week, Aug 13, things looking pretty open
... that agenda will likely be shaped by todays meeting. any additions?

[silence]

Combobox datepicker

mck: let's defer this until Jon is here

APG language for new ARIA features

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]

Date picker/combobox update

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

Priorities for APG 1.2

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!

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/08/06 19:03:39 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]