<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!

Future meeting agendas

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?

Date picker

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!

Mobile compatibility

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

Recruiting and onboarding more people qualified to do code review

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.)