W3C

- DRAFT -

August 21, 2019 ARIA and Assistive Technologies Community Group Teleconference

21 Aug 2019

Attendees

Present
Matt_King, jongund, Yohta, Jean-Francois_Hector, michael_fairchild, spectranaut
Regrets
Chair
Matt King
Scribe
Yohta

Contents


Bocoup Intros

<scribe> scribe:Yohta

Val: Excited for work with this group. I'm engineer with a particular focus on web standard. We've worked on both of this group for years.

Isaac: I'm project manager, focus on UX/UI.Before project manager, I started as graphic desinger.This project is very exciting due to my background and excited to learn about project.

JF: Base in London, designer. Joining in this group since Febulary.

Jon: From Illinois. Worked with Val before for ARIA.

Michael: Co-chair this group. Accessibility Consultant Deque System. Used to be a web engineer. Knowledge both for back/front end.

Isaac: We've started the project this Monday, and planning to last till Nov.24
... We've started 5 days full-time till next Monday. After that we'll start one day a week(Wednesday)
... From October 7th, we'll work 2 days a week. After that we'll be full time for prototype till Nov 24

Matt: Important discussion is what kind of decision should be made before Oct.28.

JF: I think it's importatnt to consider what is this we're going to test for prototype, and make a decision what is important and what is not.

Val: This is the list of questions we wanna have before testing. We'll certainly figure out.

Jon: 2 perspective should be considered. 1.User perspective. How they are gonna testing. 2.What really output look like.

Matt: We've done use-cases, which is what probelms we're solving. For the prototype, my thinking is we gonna build something intend to top problems we've defined.

Purpose is to answer questons like: -If a solution is workable in practice. -What would be the hypothesis. -What do we mean by workable. -What are concerns.

JF: If I'm correct, my understanding of purpose is: 1. Answering questions and hypotheisis 2. Something that testers can produce data at the end of the test.

Matt: They are important, but also we certainly want to demonstrate to SR developers, and get some input from them, regarding what's most important for them

Val: That's a good clarity to have.

Michael: I like the direction is going. My concern with continuing the spreadsheet are:1.Collection. 2.Datamodel 3.Presentational tool. These concerns should be separated.

Matt: At least for data collection and data model, spreadsheet is scrappy and rough. Spreadsheet help people realizing the shortcoming of the tool, and hope leads to constructive discussion to come up with alternative.
... My primary focus for spreadsheet was around what's the high-level view of the data that we can take.

Next steps

Matt: We'll meeting Val next time on Sep 4th. So how we can set milestones.
... By the time Sep. 25. How do we know we're on track. In a big picture, oppressing question is "do we do 100% custome, or do we do existing package?"
... I'd like to brainstorm to help us fugure out how to make decisions.

<michael_fairchild> https://github.com/w3c/aria-at/issues/8

Val: I can do a survey/research and come back with the insights and discuss.
... About what kind of questions we need to answer.

Matt: Most concerning to me is how customizable is data collection piece: 1.Process of inputting test cases. What are the assertion, precondition,success criteria look like.

Jon: From tester's standpoint, I think checking checkbox style should be expected.

Matt: Only if the result was incorrect/partial, we want further info.

Val: Ideally we capture SR output automatically. But really will be copying speech output.

Michael: Branching input form will be nice to have, and good question to ask.

Matt: Branching like in the checkbox example, there's a group label on checkbox, and there're multiple command you can use for checkbox. One way you have partial support is "most of the commands work, but some not" Other will be "all the command provide certain info, but not complete"
... If we have branching capability that allows users to express root cause, we can collect super granular data with few checkboxes.

Jon: You're envisioning decision tree-like assertion?

Matt: Yes. Start with some primary assertion, and branch out depending on mode. Let's say you're only expecting testers to answer 4 questions, but if one of them fails the testers would document more detail about thouse fails.

Val: I'll set up an issue, so that everybody can post their questions for the coming project. E.g."What thing you want me to research"
... There's some questions we want to answer for protytipe. But there's also questions we want to figure out before prototype. So appreciate if everybody share those questions.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/08/21 17:01:19 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
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 jongund Yohta Jean-Francois_Hector michael_fairchild spectranaut
No ScribeNick specified.  Guessing ScribeNick: shimizuyohta
Found Scribe: Yohta

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]