<scribe> scribe:shimizuyohta

Matt: We're in a phase that we want to recruite more AT type of people
... I wanna spend some time talk about detail of checkbox.

Valerie: We'd like to discuss language as well. Instructions in general. We could use checkbox as an example.

Jon: We should be able to look at the review page on branch.

Valerie: There's few things to fix, but we can merge it so that we can review.

Discuss the language used in the tests

Matt: Let's talk language, and then test plan structure.
... Let's take checkbox for example for our discussion.

<Matt_King> checkbox test plan page: https://w3c.github.io/aria-at/review/checkbox.html

Matt: If we talk about language, we have assertions and instructions.
... Highest priority will be assertions language.
... Although we need to discuss the same issue for instructions, testers would care more about assertions language. And we need to polish the assertion lanugage matters a lot, compared to instructions.

Michael: To me, both are equally important.There's still too much room for interpretation in instructions. So I think it's vital to make instructions well-written, so that anyone can reproduce the same result.

Matt: In the review report, priority 1/2/3 correspond to must-have/nice to have/shoudl have.

Michael: So we want to render the word based on that.
... I'm curious why you choose the nice to have, instead of may have.

Matt: In combo-box, nice is when you open combobox, "it could tell you how many suggested options are available".I marked it as a nice.

Jon: My concern is we need guidance for those criterion.

Matt: We don't want to give an impression that we are creating our own standard.

Valerie: For the sake of simplicity, we might want to narrow down options to required/optional.

Michael: In my opinion, must/nice/should doesn't necessary mean we have normative.

Jon: I don't think 'may' brings up the concept that it is still important.
... I like 'required' but I don't like 'optional'. 'Nice' sounds intuitive, that it's usable for users.

Matt: If SR meet all the must-have, they are providing workable experience. If they had should-have along with must-have, that means SR is doing pretty usable job.

Michael: We have assertions that refleacting SR speech that are tolerable (e.g.verbose).

Matt: If you have something innocuous, that's something workth discussing but maybe out of scope.
... Perhaps my sense is if SR does a great job, there's no unnecessary speech information.
... If that's the case, what we gonna do with something like: When should we assert that you should have user instructions.

Jon: SR developers are develop for ther products, so design language should be easier for them to digest.So design language is must have/should have/nice to have.

Michael: Sounds good, my only concern is it is very similar to RFC 119(not sure I captured this right)

Matt: We might come back to this after we get feedbacks from stakeholders. But sounds like we're having consensus for this.
... For checkbox, first test is 'navigate through group in interaction mode'.
... Michale, do you think this language used in checkbox suits to our discussion?

Michael: Yes, but also this involves language in instruction.

Matt: In the working, I took out unnecessary article. So I decided "role 'group' is conveyed".
... I was making a distinction between spoken and conveyed. If SR has some ways to convey the information, I defined it as 'convey'. Whenever not precisely happened, I marked it as 'conveyed'. When SR precisely announce the information, I used 'spoken'.

Michael: Thinking about use case of Braille output, do we stick wit the concept of speak?

Matt: I don't think so. They are output, but not spoken.

Michael: Assertions could be shared with Braille.

Matt: Yes, for the moment for our prototype, we assume we capture for speech output.
... For everything without precise speech in quote ''. use the term 'convey'

Michael: In either case whether we use quote, we want to make the decision for consistency.

Matt: We don't need to assign special meaning in quote.
... I didn't use 'the' to make it shorter.

Jon: When somethigng is conveyed, what does it specifically mean? If somebody was using tone..

Matt: There are certain convention that they become considered sufficient.

Consensus:For now, we agreed on the use of 'convey', due to scalability.

Matt: One thing I'm concerned about the assertion "The state of the checkbox (checked) is conveyed"
... We might want to capture 'when' that happened.
... I made that assertion very short.
... It seems to me 'the change in state is conveyed when checkbox is activated' sounds clearer.

Michael: There's two assertions in this task. State is more important in this case to me.
... Reason why there's two assertions is that ensure that both states are conveyed.

Matt: It might be too heavy to do that way. Instructions could literally be 'toggle the checkbox' for each is its state. If it's tri-state checkbox, each of 3 possible sates could be instructions, and assertion could be the 'change in state is conveyed'.
... I want to simplify the test, so that testers don't necessary need to reload the page to test a single test.

Michael: I'm good with rephrasing, but there are other benefit for reporting.

Matt: I get it, but that granurality sounds little too much, since we're not the developers of SR.

Valerie: Do we wanna status update for each widget?

Status update

Valerie: Erica did refactor tasks that coded from last base of project, and I'm going to merge it.
... I encoured some conflict in menubar, and I'll figure out this out afternoon.
... We also need update at command js, which I'll work on.

Matt: In our composition, we could find ways to potentially make it easier to reuse at the time you're composing the test.

Valerie: I think yet another problem is that there might be later redesign.

Matt: I've been doing the combobox, mirroring your spreadsheet Jon. I don't where to put the priority.

Jon: For assertion, default is 1. If you have something other than 1, put it in the beginning like this. 2:xxx
... We also don't use the Test_No column for encoding purposes, so you don't need to worry about that column.

Valerie: I don't push any more PR for menubar.

Matt: I'll send it to you in a excel Jon.

Valerie: We hoped to start running the test next week.

Matt: We did, but we need review before running the test.

Michael: There's a github issue to check that update.

Matt: That means all the test planned on github to read.Our goal for now is to read and review them, in the mid-week of next week.

Michael: I may not be able to finish review all of them by the deadline.

Matt: I can send it to the community 1.What we have 2.What we want. after Fridya to seek for potential contributers.

<Jemma> set up test document would be great.

<Jemma> Matt has been documenting the description of test script.

Jon: Column references that file and get contents of that file. So anything in that test file including comment will be included.

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 Erika_Miguel isaacdurazo shimizuyohta jongund michael_fairchild spectranaut 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: 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.)