<Jemma> Chair: Matt_King
<Jemma> Meeting: ARIA- APG
<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
<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
<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
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.)[End of scribe.perl diagnostic output]