<scribe> scribe: Jean-Francois_Hector

<scribe> MEETING: ARIA and Assistive Technologies Community Group for Jan 15, 2020

Meeting time

MCK: More people could make the meeting if we made it 3h later than it currently is

Not sure how wide Yohta reached for his survey (wider than the mailing list?)

Changing the meeting time to 12 Pacific sounds like a good move

MF: Agreed

JG: Better for me too, but I'd hate to lose people from Europe

MCK: Let's give this time a try and see how it goes. We can revisit later

Let's plan on it starting on Jan 22

Future plans and next steps for the prototype

MCK: Quick update on the contract side:

I just signed a draft statement of work from our contracts team

This means we're days away from being able to have Bocoup (Valérie and somebody else) back on this project

I expect that we'll start next week

MF: That's great

MCK: They'll be joining the call on a regular basis

I'd like to use this call as the primary planning call for their work

Between now and the middle of june, we'll have them close to full time. At the beginning not as much

The goal is to have a production system done by the end of June

I currently have 37 person/week allocated from them for the first half of the year (note from scribe: not sure I heard that correctly)

In the prototype work, we have made some decisions. Test format. How we want to go about building it. We haven't decided on a technology, but to go bespoke. So we've made some key decisions.

We don't yet have hosting lined up. But that's anticipated.

We do have a green line from W3C for that. I'll be on W3C servers with W3C account managements. We'll be relying on W3C authentication.

Having the W3C domain is important for the long term credibility of the project.

A really important next step is to make sure that we conceptually have full buy-in from at least Freedom Scientific and NVAccess

I've been planting seeds for them for probably about 3 years on this

MF: What are the next steps on getting them involved?

MCK: I outlined a plan. Boaz from Bocoup was going to add flesh to it. Let me find it.

I'm going to paste this here:

Actually, I'll send it as an email, on the public list

Here's the link: https://lists.w3.org/Archives/Public/public-aria-at/2020Jan/0004.html

[we're going through the email now]

MCK: We want to cover some of these patterns at a minimum; I've included more so that we can show we've considered a wide range of patterns

MF: One way to do that could be to do the tests for checkbox and combobox, as well as write the tests for some of the others

Then create a presentation for Freedom Scientific and NVAccess. In separate meetings. Address some of their concerns so that they openly support the project.

We'd have to see whether we want to make changes to the prototype.

I'd like to use the prototype as a basic for the design for the production version.

I don't think that we need to go into a design tool for what's already covered in the prototype. But it might make sense for other screens that we won't prototype.

For the parts of the UI that screen reader users are going to interact with, I'd like to mimic what's in the prototype.

One of the things we haven't yet done, is to create a way to review a test plan. At the moment the only way to do that is to run the test. That takes too much time.

MF: Is that something that we could do with Github pull requests?

MCK: What I mean is "read" a test plan.

For example if a screen reader developer wanted to see how checkbox is being tested.

At the moment, the only ways to do that is to look at some code, or run through the actual test. None of these are good for that purpose.

Instead, we need to make the VPT file and make it human readable. With all the plans, all the assertions, but not the inputs for checking what the results are.

This will help us see what we're testing, and see what'll be in the results, before we produce results.

Another way to think of this is "what is the screen reader spec for Combobox?". Because that's essentially what the test plan is.

So it should be as easy to read as possible.

We'll also use it to review tests.

Screen reader developers want to be sure that there's clear agreement on what's being tested and how it's being tested.

MF: Where in this timeline should we do test assertions/expectations for ARIA attributes or values (rather than patterns)?

MCK: So, you mean for example, extracting all assertions for, say, `aria-checked`, regardless of what pattern it's in?

MF: Yes

MCK: as we develop tests for each pattern, as part of that we'll be developing the assertions for aria attribute

In 2021, a vision is to use that data to orchestrate regression testing.

There's a section in the email about building the production system.

Initial design would happen in February.

I hope that we could be piloting something in April.

MF: What sort of time commitment do you see from everyone in the community group moving forward?

MCK: Good question. There are certain parts of this plan where the more input we have, the better the deliverables. That's especially true in the phase when we're developing the designs, and evaluating the gaps between the prototype and our use cases. And prioritising the gaps for v1

We can do everything possible to use our 1h meeting for feedback. But there'll be time when we'll need people to dig in into details, so we can come up with good decisions.

MF: There's also things like writing test plans.

MCK: Writing test plans is something that we could do now in part. We should talk about how to divide that work up.

Writing the tests plans was easier for me to do in Excel, and give to someone else to convert into VPT.

I found that focusing on the test and on the VPT syntax at the same time was too much for me at the same time.

Some of us might be more efficient at converting an excel spreadsheet into a VPT file.

We could develop minimal authoring tool as part of the plan.

How does a user input a test plan, and it gets outputted into the right format?

Using consistent language is important. And the more we write tests in spreadsheets, the harder that is. (as spreadsheets are freeform)

As soon as we have say 4 people writing spreadsheets, the burden of keeping them consistent is pretty significant.

That could be a separate workstream that the people on this call could address.

Who's available when and how much they can do is what's going to determine how fast we move.

JG: And we might be able to get some student help to build a conversion tool.
... Thanks for getting all these resources together. That's wonderful.

MCK: The only way this is going to work, though, is to have the whole team to make sure we stay on track.

One thing to think about now, is how we divide up the work between community members and Bocoup.

For what we want to do, it's pretty tight. So it'll boil down to making smart decisions. But also, the more each of us can contribute, the more we can get done.

We can think about the best way that each of us can contribute as individuals.

In terms of presenting to screen reader developers, what's important is writing the writing of the tests. So I expect to focus my time on that.

Could others help convert that into VPT format?

Next week's agenda could include: how do we plan the work we're going to do?

The current spreadsheets we've done are attached to some of the issues. We might want these sample spreadsheets in a way that's easier to access.

I'll see if I can do that.

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 Jean-Francois_Hector jongund michael_fairchild Jemma
Found Scribe: Jean-Francois_Hector
Inferring ScribeNick: Jean-Francois_Hector

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.)