Meeting minutes
Review agenda and next meeting dates
https://
Matt_King: Would anyone like to add any other topics?
IsaDC: Will we talk about James Craig's feedback on action button?
Matt_King: I wasn't planning on it talking about it today because we still have to tell James that his comments are in regards to an old test plan
IsaDC: Some of the assertions will remain, though
Matt_King: That's true. I want to point him to one of the new test plans which has similar results. If his issues still stand, then we could make a meaningful topic for next meeting's agenda
Matt_King: Next community group meeting: Wednesday May 8
Matt_King: Next AT Driver Subgroup meeting: Monday May 13
Matt_King: I won't be able to attend the AT Driver subgroup meeting on Monday. I might be able to listen since I will be traveling, but I definitely won't be able to speak
Current status
Matt_King: Goal: 6 recommended plans by June 30
Matt_King: We have 5 test plans in candidate review!
Matt_King: We've made changes in an attempt to address all open issues. It remains to be seen whether the changes actually address the issues, but it's good progress nonetheless
Matt_King: Next up are modal dialog and action menu button
Matt_King: Any questions about any of this?
Matt_King: Hearing none, we'll move on
Enhancements to APG support tables
Matt_King: Last year, we launched support tables in APG
Matt_King: We got a little critical feedback--people weren't sure how to use the data
Matt_King: We're making two changes to address that
Matt_King: The link in the agenda leads to a preview page which demonstrates what the new support table will look like
Matt_King: On the new APG example page, after the "about this example" heading (and a bunch of level-2 headings), you'll find the "assistive technology support table"
Matt_King: We also discussed this table on Tuesday in the Authoring Practices Guide call
Matt_King: There were two bits of feedback. Nobody had problems with the design of the table itself--the feedback was on the content
Matt_King: howard-e is taking care of those changes
Matt_King: the big change with what's currently in production is that this adds a column for "SHOULD HAVE assertions" as well as "MUST HAVE assertions"
Matt_King: It also gets rid of the problem with the current table which has "n/a" entries for invalid AT/browser combinations like Safari and JAWS
Matt_King: In the APG Task Force meeting, we agreed to further modify this patch to change the column titles (e.g. from "MUST behaviors" to "MUST HAVE behaviors"). We also agreed to sort the rows of the table alphabetically (they seem kind of randomly arranged right now)
Matt_King: Does anyone here have any further suggestions for changes?
Michael_Fairchild: I really like it
IsaDC: The very first cell is empty; I think it should include a column header
Matt_King: That sounds good. "Assistive Technology / Browser" might be a bit cumbersome, visually. Do you think it should say "AT/Browser", instead
Joe_Humbert: Currently, due to the contents of the other cells in that column, the very first cell could accommodate the full text "Assistive Technology / Browser"
Michael_Fairchild: I concur; the longer version ought to fit
Michael_Fairchild: the word "supported" is repeated in all of the cells, and it's also implied by the heading above and the context of the table. I wonder if we could remove it--if that would make things less noisy
Matt_King: I would support that
Joe_Humbert: Have you been getting questions about the difference between "MUST" and "SHOULD"?
Matt_King: Yes, and we have a plan for that, but let's consider Michael_Fairchild's feedback before discussing that
Matt_King: Should we use "support for MUST HAVE behaviors" as the column heading?
Joe_Humbert: That would significantly expand the visual width of those columns. Which isn't necessarily a bad thing, but it's worth needing
Michael_Fairchild: I don't think the word "support" is really necessary there, even after removing it from the cells, given the context
Matt_King: I like the idea of brevity
Matt_King: I'm also thinking about Joe_Humbert's feedback... The other change is that there's going to be a link just below the heading. That link will lead to a new page--the one I have linked in the agenda and for which I'm still drafting the content
https://
Matt_King: That will help people understand how to use this data
Matt_King: It's where we'll explain the difference between "MUST" and "SHOULD" behaviors
Matt_King: I'm thinking that the link could be something like "Learn about the meaning of the support levels shown below"
Matt_King: The term "support levels" would help emphasize that the meaning is the level of support
Joe_Humbert: the column title "MUST HAVE behaviors" doesn't tell me what those behaviors are, but I also understand that there's probably too much to say about that to fit in this table
Joe_Humbert: Could we have a deep-link from this page directly to the AT-specific results? Just because if I have to travel through the details page that summarizes ALL ATs, then the navigation is a bit cumbersome since it involves scrolling to the AT in which I'm interested
Matt_King: One thing we don't do in the reports is organize data by MUST and SHOULD. To be clear: we haven't put a lot of investment into the website for all the different possible use cases
Matt_King: That's currently appropriate because we haven't had a lot of the data, yet
Matt_King: That will make more sense (and we'll make more investment) over the next year as we start to publish more data
Matt_King: To summarize--the first column needs a header ("Assistive Technology / Browser"), and the word "supported" should be removed from the cells, and if that affects the visual layout, then consider putting the graphic and the percentage on the same line so that the cells can be shorter
Matt_King: Those are in addition to the changes already discussed in the APG Task Force meeting
Matt_King: A sixth change which could come later would be to make the AT browser names themselves into links which go to the report site
jugglinmike: Maybe we could also add a link to the column headings themselves, e.g. a "question mark" character as a superscript, that directs to the same new page
Matt_King: That might be tricky because it would appear inside the iframe
Michael_Fairchild: I don't think that's an issue
Michael_Fairchild: Separately, I'm wondering if the words "MUST" and "SHOULD" will have meaning to non-standards audiences
Matt_King: I think the common definitions of those words are close enough for those audiences
Michael_Fairchild: you're probably right
jugglinmike: Though there's also "required" and "recommended" if we really want alternatives
jugglinmike: To Michael_Fairchild's point, though, capitalizing the words "MUST" and "SHOULD", while typical in specification contexts, might look a little foreign or even off-putting to folks without that experience
Michael_Fairchild: That's a good point
Matt_King: I agree. Let's use normal casing for those.
Matt_King: Also, it seems as though the terms are surrounded in quotation marks. I don't think that's necessary, either
Matt_King: So, as an amendment to the change we were already considering, these headings should read "Must have behaviors" and "Should have behaviors"
Dialog test plan
Matt_King: The R&D version is displayed as "n/a"
Matt_King: howard-e can you run the script now so that we can add it to the test queue in this meeting?
howard-e: it may have already done the work because I'm seeing it in the table, already
Matt_King: Ah, there it is. Sorry, I was looking at radio, not dialog
Matt_King: I'm getting an error about data representation
howard-e: I'm seeing that, too. I will investigate; it should be a quick fix. In the mean time, you may have to use the link that is in the agenda
Matt_King: I'm going to advance it to "DRAFT"...
Matt_King: I'm getting the same error
Matt_King: but if we add it to the test queue, then people could look at it there
Matt_King: Let's just walk through this from the link in the agenda
Matt_King: I'd like to draw folks' attention to a specific test: test number seven
Matt_King: Test number seven is unlike any test we've had before. I hope it's clear to people
Matt_King: If you're looking at the instructions, they basically say that you're going to open the dialog, navigate to the top (in JAWS and NVDA with CTRL+Home), and then you're going to press the up arrow a couple of times (I wrote "two times" specifically to ensure that there isn't one extra line beyond the edge)
Matt_King: After that, you will read the current element
Matt_King: The one and only assertion is that (for JAWS) the position of the virtual cursor is the "add delivery" address heading.
Matt_King: Does anybody have any questions about this test or concerns about the way it's worded or anything like that?
Matt_King: Hearing none, it seems the construction of this test is acceptable!
Matt_King: Okay, we need volunteers for this test plan!
IsaDC: I'm testing with all three screen readers
Joe_Humbert: When do you need the testing done by?
Matt_King: It would be extremely helpful if we could get these all done in the next couple weeks so that, by mid-May, we have all the test plans we need to hit our target
Joe_Humbert: In that case, I volunteer for VoiceOver and NVDA
howard-e: I'm observing a bug that we've reported previously. I have a quick patch in mind, but I'd like to run it by my team at Bocoup, first. I'll have Carmen keep you posted on the progress there
Matt_King: Would automated results collection fail in this state?
howard-e: I'm unsure of what would happen. I'd recommend waiting until we resolve the issue before initiating an automated AT results collection
Matt_King: Okay, it's in the test queue, now, so we should be able to add Joe_Humbert
Matt_King: We still need one JAWS tester. Maybe Alyssa or Hadi will be available for that
Matt_King: But we're out of time for now