<mck> https://github.com/w3c/aria-practices/wiki/July-21%2C-2020-Agenda
Introductions - Welcome Matt Schad!!
<scribe> scribe: MarkMccarthy
<Jemma> Welcome Matt Schad!
<Matthew_Schad_> Thank you!
mck: still sticking with biweekly
schedule, so next meeting is aug 8
... we'll find some topics for that today
<Jemma> https://github.com/w3c/aria-practices/wiki/July-21%2C-2020-Agenda
mck: discussing date picker, tree
grids, then how to recruit more folks for code review
... anything else from anyone?
mck: huge thanks to everyone that helped with reviews and getting everything taken care of
<Jemma> https://github.com/w3c/aria-practices/pull/1362
mck: both refactors are in, all
variations we were working on are in. next big one is refactor
of the date picker dialog
... i did a thorough review of everything spec related and
editorial work. -I- think it's ready , but we don't have a full
set of approvals yet
carmacleod: i found a couple things but the one thing I'd like to see done (probably due to the refactoring): it's odd the calendar button takes focus when the page is reloaded
<Jemma> https://github.com/w3c/aria-practices/pull/1362#issuecomment-662017862
<Jemma> Carolyn's comment
carmacleod: the dialog is hidden
but focus is moved to the button afterward. that's what we want
-elsewhere- but maybe not here
... other than that, just little things
jongund: that should be easy to fix, i'll work on it now
mck: so once that's fixed you'll approve?
carmacleod: yes
mck: curt is working on the a11y
review, still need that
... i did everything but visuals and HCM
carmacleod: i can check contrast
and HCM, since you did screen reader review matt
... i can do that now
Jemma: i removed curt from reviewers
<Jemma> i updated the reviewer as you, carolyn
<Jemma> yay!!
mck: looks like we're on the way then!
mck: we started talking about this a few weeks ago but i don't think I Took down any actions for who was going to do iOS and Android work
<Jemma> https://w3c.github.io/aria-practices/examples/combobox/combobox-datepicker.html
mck: not necessarily mobile screen reader friendly (APIs may not yet support) but it should at least be functional for users not using SRs. bryan, what's your view?
<Jemma> subtopic is about Modal or non modal/Touch event
bryan: in the past, grid wasn't
well supported, but that's improved in a11y tree mappings
... the issues that existed back than may not now; that's why I
never had aria-grid markup in the whatsock calendars
... it used to be where moving focus into a grid construct
would make lots of noise, but i think it'll work better now
than it used to. we can try it!
mck: has anyone done research into how this works on mobile with preferred browsers?
jongund: i've done some testing with touch on iOS and Android and it seems to work
mck: what was the issue we saw jongund? in other words, tapping was displaying 1) the keyboard or 2) the dialog?
jongund: well that was more an
issue with the date picker
... for this, there's a button to activate it
mck: so generally this is more mobile friendly?
jongund: i think so
mck: so tapping input on the combobox one, does the dialog AND keyboard appear? and which is on top?
jongund: yes, they keyboard is on top
mck: is the dialog covered by it?
jongund: yes, but you can dismiss the keyboard
mck: don't need realtime testing, but just want to know what the expectations are
bryan: i had a feature request earlier this year - if you type in a date in the edit field, asking if the calendar could scroll to that date when it opens
mck: we're doing that now
bryan: perfect
mck: we made the calendar button with the combobox accessible even if using a screen reader. but as a sighted touch user, does this feel like behavior a typical dev would want?
carmacleod: probably not, and
I'll try it
... seems to me it should bring up the spin button based date
pickers
mck: we could put in a note since
we have a spinbutton date picker
... maybe in the intro, we could say to choose this
implemention OR that native one, and point people to what fits
best
bryan: i've seen actual calendars
on mobile, it's not impossible
... i -think- input=date on iOS defaults to a basic text
input
<Jemma> my testing in iOS phone for date picker shows that the keyboard blocks the calendar view. To select the date from the calendar, I have to dismiss keyboard first.
bryan: personally, i'd recommend both (input=date and a trigger element to open the calendar). devs might want to be able to disable specific ranges or other framework settings
jamesn: native date and datetime
on iOS 13 on an iphone. date gives a spinner on both; datetime
gives a combined one.
... iPad with iOS 14 gives a popup calendar
mck: do they work with voiceover james?
jamesn: i know the spinners do, but I haven't tested it
<Jemma> Bryan's comment on input = date on iOS defaults to a basic text input make sense because it keeps brining up keyboard.
mck: ultimately, we don't want to add much to our mobile debt
bryan: if, in some APIs, the use of type=date opens a calendar, should we use that at all?
siri: generally yes to make sure the keyboard type is changed to the appropriate one
jamesn: well type=date on chrome gives something similar on desktop, firefox might too
bryan: but a proper calendar view - should we use that?
sarah_higley: i think most browsers do that and support it; but they weren't very accessible
jamesn: +1
mck: so our date pickers could be more accessible than the defaults?
jamesn: well for iOS and Voiceover maybe not because they only have to design for their environment
jongund: what kind of docs do you want matt? they work with touch and all that
mck: goal here is to bring this
to the group's attention, have people look at it if there's
issues. best thing might be to raise new issues
... we do need to start capturing things about mobile
somewhere, what works and doesn't...
Jemma: could this be part of aria-at?
mck: won't be til late this year or next year
jongund: also note what example have been tested for HCM - we got dinged for that before
carmacleod: there's a list for that, jaws-test2 opened it. Zoe added a todo with the failing ones.
<sarah_higley> @jamesn looks like <input type="date"> doesn't work at all in iOS / Safari / VoiceOver
carmacleod: i'll add a link in the minutes
jongund: is the goal here to make every example support HCM? I was suggesting mark what we -know- works with HCM
mck: eventually, quality objective is that they all work.
jongund: that's part of why i refactored a lot of my examples
<carmacleod> Windows High Contrast Mode example checklist in this issue comment: https://github.com/w3c/aria-practices/issues/1132#issuecomment-534418273
mck: i wonder where we'll put it...
jongund: want me to update the indexing script?
Jemma: +1
mck: let's make that an issue
too, so we can track this
... and surface it easily
... maybe it can go in the coverage report for now
jongund: i want to make sure
people can easily find them if they need them
... and that the QA is taken care of
sarah_higley: we also don't test with Braille and I don't think many of our examples work well with Braille displays. If we need mobile testing I can help with some of that
mck: before you change anything
jongund, let's make sure to talk it through
... can you or jemma create an issue for that?
... skipping treegrid for now, moving on to code review
etc.
... main objective with this is to create quicker feedback
loops. people don't need accessibility knowledge but rather
real world engineering experience
... we can hopefully bring in more engineers through this and
teach about a11y on the way, AND get more work done, all at the
same time
... i wonder if sarah_higley or Matthew_Schad_ (or any others)
think that these premises are correct
sarah_higley: we already have
jslint; we could look into something like prettier if anyone
likes it or is interested
... could look into lint rules, find more that could happen
automatically. can definitely revisit the guidelines.
... i think it'd really help to reduce PR sizes and manage
scope creep
mck: agree to both - but to how
we'd bring in engineers, initially for the purpose of helping
with code reviews that can't be checked with a linter...i'd
like documentation and a good mangement process to help
that
... allow us to work faster and more iteratively.
sarah_higley: i think it'd take
some time to ramp up but it's a great idea. we should have docs
of good examples for reference
... a lot of standards are pretty generic, or as i've seen it
anyway; more stylistic. part of the problem is a lot of our
examples are diverse - so we should figure out which we want
things modeled off of first
mck: are the examples we've recently done, would those be good models? can we say why? can all that be a good start to a code guide?
sarah_higley: i think so! there's
benefit to making everything consistent, helps readaiblity and
reliability. even if there's not a technical reason why.
... would be great to pick a couple that have consistent
organization, commenting, etc. as examples, even if it means
reformatting them, then including those examples as
reference.
... some of this is otherwise difficult to capture
mck: so issue 1180, focused on code readibility, would that be helpful?
sarah_higley: i think so. we
could go through the style guide and put things there, two
prong effort.
... we'd just need to find the people
mck: i want to get it to the
point we get some people that are really comfortable with that
guide, they become core to the group and are experts at
that.
... don't necessarily need people that attend every meeting,
maybe only one a month or something. just trying to think of a
lightweight committment that carries benefit to the
group.
... Matthew_Schad_ do you think you and sarah would be willing
to collaborate on 1180, result being updating the wiki?
<Jemma> https://github.com/w3c/aria-practices/issues/1180
Matthew_Schad_: i'd be open to
it.
... one thought -- speaking of small things like semicolons, we
could probably handle that with precommit hooks
mck: we do that now i think, right?
sarah_higley: i looked into this because i was surprised about errors that should'nt have been thrown. i should look back into this
mck: is that what husky is for?
<Jemma> I support your suggestion, Matt Schad
jongund: there's a lot of JS linting. when you do a commit, it'll look for things like semicolons and all that. seemed like it caught a lot of things before that aren't being caught now, but maybe that's because i'm getting better or autocorrecting is
<Jemma> it was different package name when I created exmaples
sarah_higley: it's worth looking into again, last time i checked i remember that there's SOMETHING that does fixing. possible we could do more
<Jemma> precommit hooks
sarah_higley: or revisit the linting rules
jongund: big issue was whether to use prototype or classes - maybe add that to the list. our linter didn't used to allow classes
<mck> Here is infra documentation: https://github.com/w3c/aria-practices/wiki/APG-Infrastructure
sarah_higley: it should now
<Jemma> matt schad, what is your github handle so that I can assign to the issue, 1180
sarah_higley: but we haven't decided to add or remove any rules, or update things for ES6.
<Matthew_Schad_> Jemma, my git handle is @maschad96
<Jemma> here is the issue about HCM and mobile compatibility https://github.com/w3c/aria-practices/issues/1459
mck: i added a link to the wiki page in the minutes [above]. if you do any research, it'd be helpful to update that as you go
sarah_higley: eslint is pretty standard and has switchable rules
<Jemma> like this, Sarah
mck: this is all great. this is
one way we can improve the contribution experience for
sure.
... sarah_higley, if you're willing to take this on, the code
guide piece, that'd be wonderful
... we can collab offline
sarah_higley: i have a lot of time in the end of july/beginning of august to dive deep, if anyone else has it, let's try to sync up
Matthew_Schad_: i should have time then too
mck: i'll see if i can get some of valerie's time too
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/folx/folks/ Succeeded: s/contrast and HCM/contrast and HCM, since you did screen reader review matt/ Succeeded: s/the review/the reviewer/ Succeeded: s/abou/about/ Succeeded: s/script/script?/ Succeeded: s/it's great/it's a great idea/ Default Present: mck, MarkMccarthy, jongund, MattSchad, sarah_higley, Jemma, carmacleod, BryanGaraventa, Siri, JamesN Present: mck MarkMccarthy jongund MattSchad sarah_higley Jemma carmacleod BryanGaraventa Siri JamesN 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]