<Jemma> https://github.com/w3c/aria-practices/wiki/July-7%2C-2020-Agenda

<scribe> scribe: carmacleod

Current plan is next meeting July 21

mck: I'm liking this bi-weekly meeting plan for summer

car: getting stuff done even when not meeting

Finalizing Combo Box Date Picker

mck: Use of font awesome icon

car: it's the calendar icon in the Date Picker Dialog example

mck: is it used in the Date Picker Combobox example?

jemma: yes, it's the drop-down arrow

mck: would prefer not to have extra dependencies unless necessary
... requires extra work to open in CodePen

jon: it's been there since the beginning.
... we should show alternate technologies, and show how to draw focus ring around font awesome images
... and show how to use them in high contrast mode

jemma: actually, the chevron icons (next previous year) in the dialog are font awesome, not the drop-down triangle (that's an svg)

mck: ok, so we're all ok with using fontawesome where it brings value over creating our own svgs
... we need to add font awesome to the source code section, which contains all source code needed for this example
... need before we can add Open in CodePen button

jon: we can just grab the source - it's just css

mck: is there a licensing issue?

jemma, jon: I don't think so - it's MIT license

mck: for now, can use cdn

<Jemma> Behavior of space in calendar

Behavior of space in calendar

mck: should space close the datepicker?

jon: we discussed, and we decided that if we provide a multi-select date picker, we will need space to keep the dialog open

mck: don't want space to work one way in single select, and another way in multi select
... might want to add a point about this in the Accessibility Features section
... will open a new issue about explaining why space and enter are different (want to merge this PR)
... Final approving reviews are all in
... Jon had one reservation about Accessibility Features not having enough detail about some of the high contrast was done

jon: that point was deleted completely

mck: I don't remember removing that point

jon: let me look - ok, for hover and focus - that's still there

mck: Mobile touch start issues

<MarkMccarthy> carmacleod: i tried it on my iphone, and once i focused it, the dialog opens but doesn't get focus. the keyboard comes up, but you can't swipe because the dialog is open

<MarkMccarthy> ... then the keyboard covers too much information, making the whole thing unusable. you have to finger browse to reorient yourself and find out more info, but even that is tricky.

<MarkMccarthy> ... i found -one- way to do it. if you find the "choose date" button and double tap that, the dialog opens properly, gets focus, etc.

<MarkMccarthy> mck: so I didn't kknow double tapping the input would open the dialog

<MarkMccarthy> carmacleod: it's because it's a combobox

<MarkMccarthy> carmacleod: it opens, but can still be typed into (because the input has focus)

<MarkMccarthy> carmacleod: not as much of an issue with a mouse, but same issues persist

<MarkMccarthy> mck: so if tapping the input opened the keyboard and tapping the button opened the dialog, would that be better?

<MarkMccarthy> carmacleod: maybe, but that might cause some weirdness in people's expectations

<MarkMccarthy> mck: my thinking is tapping the input means you want to type the date, tapping the button means you want to tap the date. right? hmm

<MarkMccarthy> jongund: i can do some testing as to why that's happening

<MarkMccarthy> jamesn: if there's a modal we must move focus, right?

<MarkMccarthy> carmacleod: but then we can't type?

<MarkMccarthy> jamesn: right. so what i've had to do with other projects is making it a non-modal that could be chosen to be interacted with

<MarkMccarthy> jamesn: are we diliberately not moving focus? or just a mobile/touch thing?

<MarkMccarthy> mck: i'm still wondering what the downside to my suggestion of input vs. button workflows would be.

<MarkMccarthy> jamesn: visual users would still want to see the calendar when typing a date in

<MarkMccarthy> jongund: we're moving focus into the dialog though

<MarkMccarthy> carmacleod: only when the keyboard is used, not mouse

<MarkMccarthy> mck: if you click in the input, you don't want to move focus, that seems fair.

<MarkMccarthy> jamesn: if we're leaving focus out of the dialog, it can't be modal

<MarkMccarthy> mck: so maybe we want a "semi-modal", where when focus is inside (from SR perspective), you must close to get out of it

<MarkMccarthy> mck: practically, it doesn't need to be modal for any reason. we still have tab trapping etc., it wouldn't change kbd functionality

<MarkMccarthy> jamesn: because we're putting it in the same place in the DOM the modal-ity of it doesn't matter much

<MarkMccarthy> mck: non-modal with SR should still have to execute a command to get out of the dialog

<MarkMccarthy> jamesn: but if you're not in a modal....?

<MarkMccarthy> mck: that's still the expectation though

<MarkMccarthy> jamesn: how can we do that unless it's modal?

<MarkMccarthy> mck: in both cases you don't read outside by default. e.g. if you're in a window with JAWS, you're only in that window. if you want to read outside the window, press ins+r and then you're outside it

<MarkMccarthy> mck: voiceover has these options too

<MarkMccarthy> jamesn: how does that reconcicle with wanting to leave focus outside some thing, but still have it be a modal?

<MarkMccarthy> mck: so i think the decision is that this is non-modal

<MarkMccarthy> jamesn: i think then that this would be okay.

<MarkMccarthy> mck: this is a future change - NO CHANGES right now!

<MarkMccarthy> mck: this might be an example of a non-modal dialog

<MarkMccarthy> mck: likewise for the current date-picker dialog

<MarkMccarthy> mck: this is probably a separate issue though

<MarkMccarthy> mck: should we prioritize this immediately after merge? or...

<MarkMccarthy> mck: we've got some time before ARIA 1.2, but this will take a chunk of time to fix

<MarkMccarthy> Jemma: so right now - what problem does this solve? carmacleod found 2 issues for screen reader testing (chrome+NVDA, and NVDA+Firefox crashing)

<MarkMccarthy> Jemma: but right now we can't resolve mobile touch issues, right?

<MarkMccarthy> mck: that's all correct

<MarkMccarthy> mck: tl;dr: good for matt to merge?

<MarkMccarthy> carmacleod: it's still crashing for Firefox+NVDA

<MarkMccarthy> MarkMccarthy: +1

<MarkMccarthy> mck: so then it likely is not a bug in our code

<MarkMccarthy> MarkMccarthy: Firefox 78.0.1 and NVDA 2020.1 for me

<MarkMccarthy> carmacleod: okay, yes, it -doesn't- crash if NVDA not running

<Jemma> my firefox 68.90 version and it does not crash

<MarkMccarthy> jongund: i don't crash with NVDA and FF 78

<MarkMccarthy> mck: so we can merge AND report this bug to Mozilla

<MarkMccarthy> mck: we're merged!!

<MarkMccarthy> carmacleod: exciting!

<MarkMccarthy> mck: i was thinking that the next thing to push on is editor menubar changes?

<MarkMccarthy> mck: should be very close to done

<MarkMccarthy> mck: do you agree jongund?

<MarkMccarthy> jongund: yeah, that'd be good. they're just minor JS updates, really

<MarkMccarthy> mck: if we need code testing/engineering, I'll talk to valerie next week

<MarkMccarthy> mck: i'll merge range related properties too

<MarkMccarthy> mck: thanks everybody for all the hard work and getting us this far!

<MarkMccarthy> mck: reminder, next meeting is on the 21st

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/clash/crash/
Present: mck Jemmaku carmacleod MarkMccarthy CurtBellew jongund
Regrets: SarahHigley BryanGaraventa
Found Scribe: carmacleod
Inferring ScribeNick: carmacleod

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