<Jemma> Chair: Matt_King

<Jemma> Meeting: ARIA- APG

Git Workflow

<Jemma> scribe?

<scribe> scribe: carmacleod

mck: Sarah drafted an outline of github workflow

sarah_higley: mostly for larger PRs - not for one-off PRs - i.e. big example PRs that gt dragged out for a long time
... create a feature branch that multiple people can make PRs against
... someone does the doc, someone else does the example, someone does the tests, etc
... make the PRs as small as possible, and review them as they go into the feature branch
... bite-sized chunks, can freeze after a specific date, then merge to branch, then do a final review before squash-merging to master

mck: a key part here is how you divide up the work. it's in scoped sections, so if divide up into sections, should not have conflicts
... tests are all in separate files, so that's easy
... you kinda want to get the basic functional design down before working on visual design?
... we use the git history to create a change log

<Jemma> https://github.com/w3c/aria-practices/wiki/Authoring-Practices-Change-Logs

jongund: will there be more like task forces, where people would work collaboratively to create an example
... this is a new model of multiple people working on examples, instead of one person

sarah_higley: use the feature branch in a more regimented way, nobody commits directly to it without PRs

mck: wouldn't want to make it a protected branch because those are difficult to manage

sarah_higley: right - it would be by convention, not formally protected

mck: save the discussion about squashing vs merging for later - would require a significant revision to the way we do change history
... as we think about moving the APG towards a web site as opposed to a document
... long term, partnership with MDN so that can access content through them

jongund: anything that would improve the PR process and encourage more people to contribute is good

<MarkMccarthy> carmacleod: one question - from the POV of a reviewer, github's suggestion feature was pretty cool

<MarkMccarthy> carmacleod: over time, i occasionally would push them in because they take up too much space, physically and mentally, and/or they wouldn't get merged

<MarkMccarthy> carmacleod: i'd never do that for code, just editorial changes. but i think that maybe we generally should -not- use suggestions

<MarkMccarthy> carmacleod: making lots of suggestions seems to generate lots of emails and noise for everyone

<MarkMccarthy> mck: i think you can batch review/push commits, select what you want to add to that. but i'd have to look into it

<MarkMccarthy> carmacleod: it's quick, right? that's the good thing. you don't have to go into an editor or make PRs and all that.

<MarkMccarthy> mck: i'm thinking that, if it's editorial and there's reasonable confidence in the changes, just fix it and don't worry about the reviews

<MarkMccarthy> MarkMccarthy: +1 to mck

<MarkMccarthy> carmacleod: what does everyone else think?

<MarkMccarthy> sarah_higley: if someone wants changes committed, as long as they (as the branch owner) knows, sure go for it. but don't do it if someone isn't expecting it

<MarkMccarthy> sarah_higley: as long as we make sure the PR owner/branch owner has control over their branch and isn't surprised by anything

<MarkMccarthy> mck: yep, that's a good convention

<MarkMccarthy> mck: and if I ask you carmacleod, for instance, for editorial review, go ahead. or we can have a conversation beforehand that you'll be making changes etc. either way as long as -I- know where changes are coming from

<MarkMccarthy> mck: so maybe some of this is tightening up team communication and general convention, outside of github's specific constraints

Add browser and AT support notice

<Jemma> https://github.com/w3c/aria-practices/pull/1404

<Jemma> https://raw.githack.com/w3c/aria-practices/1228-support-notice/examples/dialog-modal/dialog.html

<Jemma> https://raw.githack.com/w3c/aria-practices/1228-support-notice/examples/dialog-modal/dialog.html

mck: Zoe started the coding work, and Simon finished up last week

<Jemma> https://raw.githack.com/w3c/aria-practices/1228-support-notice/examples/grid/dataGrids.html

mck: Simon put the notice after the "Example" h2
... I always expect the example code to immediately follow that h2
... Jemma fixed it so that the notice is before the "Example" h2

jongund: maybe put it after the h1?

<zcorpan> hi all. Note that https://w3c.github.io/aria-practices/examples/carousel/carousel-1.html has a section before "Example"

jongund: that way it would be in the same place on every page (right now, it depends on how much text is in the description for the example)

<MarkMccarthy> MarkMccarthy: +1 jongund

<jongund> +1

CurtBellew: I also like having it after the h1

mck: let's remove the first link on each example page
... the one to Browser and AT support

Jemma: I'll open an issue to do that

Select-only combobox

<MarkMccarthy> carmacleod: i'm talking with James Craig on Thursday about the Safari issues we're having, so maybe we want to wait to merge this until we talk about it

<MarkMccarthy> sarah_higley: would this change any code? i think the other comboboxes have similar issues with Safari

<MarkMccarthy> carmacleod: i'm not sure - and thinking about that, maybe we don't need to wait

<MarkMccarthy> MarkMccarthy: this was also a problem with Mojave

<MarkMccarthy> carmacleod: which is why I went to Catalina, and that still had problems

<MarkMccarthy> carmacleod: is anyone here a proper VoiceOver user? Like, I'm not missing any steps or anything, right?

<MarkMccarthy> mck: no, you're not. I'd say I use it 15-20% of the time and it -should- work as described; it shouldn't quite need the VO commands. I wonder if there's an aria-activedescendent issue...

<MarkMccarthy> carmacleod: and, even VO+Space doesn't do anything, no drop downs or anything. but that wasn't working either. I -think- it's a bug

<MarkMccarthy> sarah_higley: specific voiceover commands haven't worked with any non-native control, right?

<MarkMccarthy> mck: what I meant is that you can operate most widgets using VO commands and not webpage commands, other than typing. so in this instance, you could use ctrl option space and ctrl option right/down arrow, and you could still interact

<MarkMccarthy> carmacleod: -that- I could do, but I wouldn't want to fight so long with it to get something done

<MarkMccarthy> carmacleod: ctrl option space worked -inside- the listbox to -select- something, but it didn't -drop down- the listbox. steps are in the issue

<siri> what is the issue number?

<MarkMccarthy> PR 1396, siri

<siri> Thanks

https://github.com/w3c/aria-practices/pull/1396

Date-picker combobox

https://github.com/w3c/aria-practices/pull/1413

<Jemma> https://github.com/w3c/aria-practices/pull/1413#issuecomment-637230837

<Jemma> Curt's comment

mck: regarding using aria-label instead of abbr, it overrides the th label. Might be ok in this case, but in general case might not want to be different.

<siri> +1 Curt

CurtBellew: I have found that abbr is not as well supported

sarah_higley: abbr only works with JAWS and VO on macOS Safari - doesn't work on anything else

mck: it's an awful experience to hear "We" and "Su" instead of Wednesday, Sunday
... we should open issues to get the screen readers to support abbr

sarah_higley: other option - could have the full text in the th and use css to show only the first letter

jamesn: I vote for exposing screen reader lack of support and see if we can get any movement on fixing it

mck: +1

<MarkMccarthy> +1 jamesn

sarah_higley: ok, the only thing is that this example is not demonstrating abbr

mck: it is an accessibility feature - just not a well-supported one

jamesn: I got them to put abbr back into the spec

mck: hats tipped to you!
... I think it does fall within scope of the example

sarah_higley: just want to mention that devs will copy the code

<siri> +1 Sarah

mck: it's a good pattern, we need to highlight that this should have better support

<Jemma> https://github.com/w3c/aria-practices/pull/1413

<siri> We did discuss about place holder when I was doing visual design review for 1017

<siri> Do you want to change it as hint?

This is scribe.perl Revision of Date 
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/Worflow/Workflow/
Succeeded: s/ets/etc/
Succeeded: s/editorial./editorial changes./
Succeeded: s/emails/emails and noise for everyone/
Succeeded: s/constraintsa/constraints/
Succeeded: s/1396/PR 1396/
Succeeded: s/commnet/comment/

WARNING: Replacing previous Present list. (Old list: mck, carmacleod, MarkMccarthy, JemmaKu, jongund, jamesn, siri, sarah_higley, CurtBellew)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ mck, carmacleod, MarkMccarthy, JemmaKu, jongund, jamesn, sarah_higley, CurtBellew

Present: mck carmacleod MarkMccarthy JemmaKu jongund jamesn sarah_higley CurtBellew Siri
Found Scribe: carmacleod
Inferring ScribeNick: carmacleod
Agenda: https://github.com/w3c/aria-practices/wiki/June-2%2C-2020-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: 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.)