W3C

- DRAFT -

ARIA-and Assistive Technology Community Group

01 Jul 2020

Agenda

Attendees

Present
Matt_King, JemmaKu, RobFentress, michael_fairchild
Regrets
Chair
Matt King
Scribe
michael_fairchild

Contents


<Jemma_> Chair: Michael and Matt

<Jemma_> Meeting: ARIA-AT

<scribe> scribe: michael_fairchild

(briefly discussed issue 280 - decision was to wait for jha11y to be on the call)

resolving issues from the pilot

Matt_King: we should have one pull request per test plan, because each test plan is a single CSV file. The best way to avoid merge conflicts is to make all of the changes in one PR.
... we don't have to necessarily fix all of the issues in one PR. We could do multiple PRs in series (one after the other).
... the first thing you want to do when submitting a PR is to list the issues that it resolves.

michael_fairchild: and you would only submit a PR for fixing the test plans rather than results, correct?

Matt_King: correct

rob-fentress: there was an issue where the output was different when you used the tab key to navigate into a group, vs when you used shift+tab

Matt_King: if there are two commands that do exactly the same thing, then it is fine for them to be listed together. However, if commands can yield different output, then they need to be in different columns in the CSV.
... is that clear?

rob-fentress: yes, in principal. I'll need to dive in to know for sure.

<rob-fentress> https://github.com/w3c/aria-at/wiki/How-to-contribute-tests

rob-fentress: do we need to adjust the instructions to handle the case where we need to issue several commands (in to or out of a group for example)

Matt_King: we should cover this in training, because it's not easy to convey in the test runner exactly how many times you need to press the command. Because different screen readers handle this differently; some screen readers have a stop for the edge of a boundary, while others announce the boundary as part of the first stop inside of the boundary

rob-fentress: (mentioned issue about VoiceOver instructions for interaction mode)

Matt_King: that's a bug that should be fixed. The CSV file needs to be updated. There is a column that defines which tests apply to which screen readers.

rob-fentress: how would the harness handle mobile screen readers?

Matt_King: hopefully we could just add more screen readers to the applies to column in the CSV
... the problem with this approach is that we don't have a robust way of ensuring that we don't have different exceptions for different screen readers

Jemma_: what does that mean?

Matt_King: when editing tests and adding assertions, it could be easy to overlook some screen readers

michael_fairchild: Rob, do I understand correctly that you will work on a PR for a few of these issues?

rob-fentress: yes, I'm trying to identify the simplest thing to start with

Matt_King: it would be great to get some feedback from you on where we can improve documentation around contributing and writing tests
... we should avoid including documentation about the mechanics of github within the documentation about how to write tests

rob-fentress: sometimes when we programmatically send focus to an element, VO will start announcing from that point. Should we stop sending focus programmatically?
... there can also be contextual behaviors of screen readers where what is announced depends on what commands you performed previously

Matt_King: I know VO tries to be helpful and avoid extra verbosity in some situations

(discussion about screen reader bugs, vs authoring bugs, vs browser bugs)

Matt_King: is it okay if we next met on July 15th for the next meeting?

rob-fentress: I might be a little late, but yes that works

Matt_King: michael_fairchild - there is one issue in the harness which I think you were working on where there was a limit on the number of assertions.

michael_fairchild: yes, I have a PR in for that

Matt_King: the other thing about the harness, was to change the output text input to a text area. can you work on that?

michael_fairchild: yes, I can fix that

Matt_King: on the 15th, we can discuss more about how to resolve conflicts

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/07/01 20:01:22 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

Present: Matt_King JemmaKu RobFentress michael_fairchild
Found Scribe: michael_fairchild
Inferring ScribeNick: michael_fairchild
Agenda: https://github.com/w3c/aria-at/issues?q=is%3Aissue+is%3Aopen+label%3AAgenda%2B

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]