W3C

- DRAFT -

October 30, 2019 ARIA and Assistive Tech Community Group Telecon

30 Oct 2019

Attendees

Present
spectranaut, shimizuyohta, michael_fairchild, Matt_King, jongund, Jemma
Regrets
Chair
Matt King
Scribe
shimizuyohta

Contents


<scribe> scribe:shimizuyohta

Overview of prototype

Matt: Last Friday, Valerie and I went through implementation of prototype.

Valerie: I'd like to discuss plan for coming few weeks and like everyone's feedback.

<spectranaut> https://github.com/w3c/aria-at/issues/13

Valerie: There are 2 stages, Stage 1: build aria test harness. Goal of this is to create js that everyone can open in their local browser.
... Stage 2: Write a simple test runner for the tests.
... By the end of this test run, you can download structured file of test results, and summary of the test.*See Github page for todo in each step.

Michael: What Javascript needs to be executed?

Valerie: It is essentially getting the preconditions is met.

<spectranaut> test format: https://github.com/w3c/aria-at/pull/12

https://github.com/w3c/aria-at/issues/13

Valerie: I'm thinkign to use vanilla javascript, anyone okay with that approach?

JG: Is there any other technologies we can use?

Jemma: There is no other blocker for using react.js for testing framework.

<Jemma> s/there is/I think there is

Valerie: Is it okay to support these modern browsers?

Matt: We gonna have the discussion. Not even Microsoft covers IE for their latest service. You don't have to cover IE for now.

JG: Did we decide where to host this?

<Jemma> me rethinking that react.js issue, if the testing framework should be used by other people, should we go with vanilla js? we can discuss more when we are close to finalizing the testing framework.

Valerie: We can start with Github, mostly to test.

Matt: One thought is I just thinking I might want to save after couple of test. Having features to save anytime. Once you save, that'll save all the previous work.

<spectranaut> https://spectranaut.github.io/aria-at/tests/checkbox/operate-checkbox.html

Discuss demonstration draft

Valerie: For demo part, what I've done is write draft to start thinking about this API. See the Pull request I made above.

Matt: If you click 'success' what prompt testers would see?

Valerie: We need to discuss that, but we can come back to this after we went through these overview.

Matt: You could say 'all passed'/'all failed'/'partially failed'

Valerie: In partial failure/failure case, it asks you to add what command had failed.

Matt: I just wanna make sure when I press partial failure button, we want to see what happened.

Valerie: I'm tyring to think how to display the same test for interaction mode.

Matt: This is about how we define test. Maybe we want to separate test depending on mode? It make sense if teh testing is ordered in sequence way. e.g. Test widget A in reading mode, and then interaction mode.
... What I was thinking is technology agnostic. That part of what you're putting in the test file itself. There would probably three clear thing about SR testing.1.Action/2.Object/3.Mode

Valerie: But not all the SR has this concept of mode?

Matt: For mobile SR, this concept of mode is fuzzy.

Valerie: I'd like to discuss mapping of command and user task based on JF's issue next week.

https://github.com/w3c/aria-at/issues/14

<spectranaut> different ways of displaying a test:https://github.com/w3c/aria-at/issues/6#issuecomment-521349855

@Jemma, I just posted JF's issue above.

JG: The actual test page would be another page?

Valerie: Right, users will be propmted to the new page in a new window.

Matt: I was envisioning the overview and instruction would be provided in the test page, and carry out the test in a new page.

JG: My point is I didn't want to force users to open whole bunch of pages.

Michael: Cross frame messaging would solve that challenge.

Valerie: There's some tasks that are not clear enough for things like checkboxes.

Matt: Being able to have precise control over instruction for users is important. Do we writhe this instruction for each SR?
... There might be some cases we want to have parameters.e.g. All the test instruction will be the same except VO.

Valerie: We need to have enough test material to adjust that.
... The files I put the test information into can be refered from the only pull request from the Github.

Matt: Is there any other critical input you need from us?

Valerie: Opening the tes page is next step. I still have some days to incorporate feedback for the work I've done, so I'll open the issue for the feedback after the meeting.
... Task for everyone is respond/give some feedback for: 1.JF's issue 14 2.Test draft

<Jean-Francois_Hector> apologies i'm held up in a meeting, I might not be able to join today

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/10/30 17:11:54 $

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)

FAILED: s/there is/I think there is/
Succeeded: s/that/react.js/
Present: spectranaut shimizuyohta michael_fairchild Matt_King jongund Jemma
Found Scribe: shimizuyohta
Inferring ScribeNick: shimizuyohta

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]