Meeting minutes
Test plan schedule for APG examples
Matt_King: We'll postpone this until next week when Lola can join us
Matt_King: (Next week's meeting is a Wednesday meeting)
[scribe error: we WILL discuss this topic today]
Matt_King: We're soon going to be rewriting some test plans, so we want to be able to plan for that
Matt_King: I think there are a couple of clear winners in terms of where we ought to focus
Matt_King: I've put together a spreadsheet with analytics from APG: https://
Matt_King: When you sort by visits, the ComboBox appears to be the most sought-after (36,000 visits)
Matt_King: But when we're batching work up, we have to be careful not to choose simply giant plans
Matt_King: We have to make our way through this entire list, eventually, so we should include shorter plans (or those that are less likely to raise contentious issues) along the way
Matt_King: Along those lines, I'm thinking of "Accordion"
Matt_King: the top three are Combobox, Accordion and Tabs
Matt_King: Accordion is similar to Disclosure
Matt_King: Does anyone have any insight into my intuition that Accordion would be fairly straightforward and we should move on to that one?
James_Scholes: We've already written a plan, so it's also good from that perspective
IsaDC: Accordion has 30 tests
Michael_Fairchild: I agree that Accordion is a good choice
James_Scholes: looking at the Candidate Review page in ARIA-AT App, the action menu button is in the "candidate" phase
Matt_King: Vispero has already started working on that
Matt_King: Because we already have the one "Disclosure" example, and because it's somewhat similar to Accordion, what do we think about choosing one of the Combobox examples for priority number 11?
Matt_King: "Select only" is simpler than any of the ones with autocomplete
James_Scholes: but we already have test plans for the examples with autocomplete
IsaDC: Autocomplete "both" is huge--it has 60 tests or more
Matt_King: The one thing about "Select only combobox" is that you can often used a plain HTML select element in its place
James_Scholes: If I were to choose one that I see often and that I consult on often, I would choose "editable with list autocomplete"
Michael_Fairchild: I think they're all pretty popular. I think "select only combobox" is popular because unlike the native "select" element, it allows authors to style options
James_Scholes: But it doesn't work well in Safari
Matt_King: What about the "selfish screen reader" point-of-view? Which of these do we struggle with the most?
Matt_King: What happens to me a lot is that I press the "down arrow" key and get nothing. However, I almost never know if that's due to a bug in VoiceOver
Matt_King: Even if the one in APG works correctly, sometimes small differences in the implementation affects the screen reader (even when it doesn't appear that those differences ought to matter)
Matt_King: In my day-to-day life, I encounter more problems with editable ones than "select-only" ones. But it's a hard call to make that way
Matt_King: I may be biased because I use the Mac at work, and I hardly use it out on the wider web
Michael_Fairchild: This may be a bit of a tangent because TalkBack is not in scope for what we're doing right now, but ListBoxes are broken in TalkBack pretty much across the board
Matt_King: Figuring out how to do a test for a mobile screen reader, now that we have the new V2 format, is just a test execution concern (V2 addressed the test writing concerns we had)
Matt_King: So we still have to figure out how we're going to collect that data, but I'm hoping we'll have a little time before the end of the year for Bocoup to start digging in to that
James_Scholes: we know people would like to style the select-only combobox. Meanwhile, I can't recommend that any client uses that pattern because it doesn't work in Safari.
James_Scholes: But I don't think I've ever seen anyone try to implement it in the wild
James_Scholes: But I personally see editable comboboxes everywhere
James_Scholes: We can choose the example that's all over the web, or we can choose the one that developers would like to use (even though it doesn't work in Safari)
Matt_King: I want to lean toward the "select only" example first because all of the issues with writing the test which would pertain to the dropdown are covered
Matt_King: But it doesn't have any of the complications of test-writing that concern interacting with the input
Matt_King: So let's get the dropdown part down, first, and then the lessons we learn from doing "Select only" should be applicable to doing "autocomplete both"
Hadi: in a single-select, when I go to a select box, do I need to differentiate that it is a single-select or that it is a multi-select?
Hadi: the behavior of the two is very similar. For example, in single-select, you arrow up and down and hit enter to close the box. But in a multiselect, selection is followed by a finalization step
James_Scholes: I agree, and I think that the most appropriate pattern to use when you have a multiselect that is filterable--that can be a tricky question to answer
James_Scholes: ...but APG does not have a multiselect example to test
Matt_King: Though we do have a multiselect list box
Matt_King: There's also that pattern that some people refer to a "pill list"
Matt_King: I just marked "Select only combobox" as number 11 in the sequence
Matt_King: Action menu button is 9, disclosure is 10
Matt_King: We might round out this year by marking Accordion as number 12
Hadi: That sounds fine to me
Matt_King: So we have 1 through 12 marked here. I think that gives us enough direction for the time being
Matt_King: We could discuss what would be 13 and 14. I think we have enough data to discuss that, now
Matt_King: But I think we should get through the "select only" combobox draft review before we think about how to prioritize "Select only combobox both"
IsaDC: Are we going to refactor the first eight?
James_Scholes: The test builder isn't ready yet, so we have to refactor and then wait for that
James_Scholes: by the time we get there, we may have refactored a bunch of them
Matt_King: When we run the new test preview code, we don't know if we'll discover any new challenges there. It's kind of a wildcard
Matt_King: If we were going to take on another pattern that's a little different and also very popular, Tabs seems like a good candidate
James_Scholes: we do have a test plan for Tabs
IsaDC: At the beginning of this year, we had two test plans, and the examples changed, so I rewrote both test plans
Matt_King: There are two "tab" examples: "automatic activation" and "manual activation". Which should it be?
James_Scholes: Goodness me!
Justin: I think automatic activation is more common
James_Scholes: automatic activation is the default (and likely) only paradigm available in Windows
Matt_King: On macOS, it's the opposite!
James_Scholes: we always try to have automatic be the default. We generally only advise manual tabs if loading the content requires non-trivial resources
Justin: in our component library, we have a manual activation pattern. I don't know how often it's used, though. I haven't seen it in the wild
James_Scholes: the new Slack interface has manual tab activation
Matt_King: I think I see both in everyday life.
Matt_King: As a screen reader user, I haven't noticed that there are any more problems with one or the other
James_Scholes: Inevitably, when we take on manual tabs, we're going to have a conversation about whether the "not selected" state is conveyed. For that reason, I'd like to put off manual tabs
Matt_King: Okay, we'll plan on prioritizing automatic tabs. We'll kick the issue James_Scholes just discribed down the road
Matt_King: I'm pretty excited that we have some new stuff with comboboxes and tabs coming up. I think that will be very valuable to the APG
Next app deployment
Matt_King: I have been doing testing, and I see howard-e has made a draft pull request for the deprecation date
Matt_King: I haven't been super-methodical, though. I haven't tested every aspect of every GitHub issue. I've tried to focus on the things that I thought were the biggest changes or the most critical workflows
Matt_King: Has IsaDC or James_Scholes had any more time to look at the staging server? Do you have any concerns?
Matt_King: I think because we are not actively testing right now, the risk of deployment is on the lower side
James_Scholes: When are you planning on doing the deployment?
Matt_King: I'd like to get it out there when we're aligned. I want to make sure that the data which is getting surfaced is correct. That's the most important thing to me
howard-e: I can land the "deprecation date" fix shortly after this meeting
howard-e: On the MVP board, that's the only other active "must have" item that's still pending
Matt_King: If you add that to staging, and I were to test and approve it later today, would it be possible to do a deployment tomorrow?
howard-e: I prefer Monday
James_Scholes: Monday works for us, too. That gives us some time tomorrow to put it through its paces
Matt_King: I also see that there was a fix for the wording about the phase names in the "plan version" table.
howard-e: I've reviewed that. There was an item that I left some feedback on. Once that's addressed, I can include it in the next deployment
Matt_King: Let's plan on a deployment for Monday, then, assuming that the reviews go well
Matt_King: I still have not done a final pass on the documentation in issue 977
Matt_King: All the V2 documentation which is based on that is accurate and complete, though
howard-e: and I'm the one working on the builder for V2
howard-e: I'll be submitting a pull request against your work later today--just some typos and whitespace fixes
Matt_King: Great!
Matt_King: I think we're in a great place. Some good, exciting decisions today. We'll be talking about AT Driver on Monday, and this group will meet again on Wednesday