<michael_fairchild> Hey folks. Regrets for today, I'm stuck in another meeting. Wish I could be there.

<scribe> scribe:shimizuyohta

Matt's new version of assertion

<mck> Link to latest spread sheet in github issue 5:

<mck> https://github.com/w3c/aria-at/issues/5#issuecomment-514649962

Matt: Trying to stick to basic 3 concept. 1.Read 2.Navigate 3.Operate
... Test name columns are not necessary unique. User tasks columns are unique.
... Screen Reader mode are either reading or interacton.
... Tested Elements columns are example of are element tested. Changed the name to make it more accessible for non-technical users.
... Level of support has 4 options. Full/Incorrect/partial/no support.
... Output Notes columns are used when testers want to capture same information/test, but in a different announcement depending on SR.
... Other comments is where tester's observation/opinions/suggestions goes.
... New raws added was last row 20. Elements we're testing is menu. However, we're testing orientation here.
... Questions or Comments.

Yohta: How we could determine scope of testing(row)?

Matt: There are some elements not listed in the table, since they are implicit. For this you might need to have SR experience. They are user's task oriented.
... For different SR, probably column H should be changed depending SR.

JF: We had discussions about granurarity whether one row should test multiple expectations. In Matt's assertion we see combining multiple expectation in one row. Is it okay?

Matt: Sometimes boundary of expectations are difficult separate. When you reporting a bug for a SR developer, you wouldn't rase 3 separate bugs.
... So considering the potential use of the document for future communication, I think current granurarity would suffice.

JF: Make sense.

Design a simple way for testers to contribute.

<Jean-Francois_Hector> Test Page July 3 Prototype: https://test-page-jfariaatjuly3.now.sh/

JF: In my first version, I put together table. Key difference is in most recent version, I separated rows in more granular level.
... First question I tried to answer is "How can we make it for testers to understand what they do?"
... Tried to make it understand at a glance, and easy to develop, so that's why it is made in table.
... There are only two columns that testers can input, so that it is more easy to orientate.
... I merged Matt's "User task" and "Key command" columns into one "When" columns.

Matt: We might need to adjust "When" column because all the key command would be different.

JF: I've also used under "Given that" column, I spanned multiple rows, which I haven't done in spreadsheet so far. This helps sighted users understanding structure of the table.

Matt: We still might want to have column to make notes of what SR did/actual result.
... Because partial support, you need to add reason of what went wrong.
... I think we can integrate row data like I did today into the interface like JF's.
... I think we need add several columns. "What SR say" "What was wrong" "General comment"

JF: I will explore value of make it simple and add some columns.