discuss agenda

<michael_fairchild> Matt would like to discuss the results of 'Exploratory Test of Layout Grid Example 1'

<mck> Matt also wants to talk about facilitating contributions

<michael_fairchild> scribe: mf

<michael_fairchild> Matt: Any other topics that folks would like to have on the agenda?

<michael_fairchild> Jon: Yohta would like to discuss the topic of assertions

<mck> scribe: Matt

Yota's work on assertions

<shimizuyohta> https://drive.google.com/drive/folders/1pOwoCWpT9uJgZZxFd36RHn9iBOiW9Tae

<mck> Yota: working on documenting assertions

<mck> diving behavior based on roles and kb function.

<mck> Can test how each screen reader behavior works

<mck> jf: each assertion would be pass or fail

<shimizuyohta> https://drive.google.com/drive/folders/1pOwoCWpT9uJgZZxFd36RHn9iBOiW9Tae?usp=sharing

<mck> Folder contains an excel sheet with lists of assertions

<mck> Example assertion:

<mck> includes an initial condition, an action, e.g., press tab, and describes result.

<mck> mk: sounds like it is asserting what the example does, not what the sr does.

<michael_fairchild> scribe: mf

<michael_fairchild> Matt: keyboard assertions don't necessarily map to screen reader specific assertions

<michael_fairchild> Matt: for screen readers, we should divide assertions into two buckets based on screen reader mode: 1) browsing mode assertions and 2) interactive mode assertions

<michael_fairchild> Jon: Does VoiceOver have the concept of modes?

<michael_fairchild> Matt: sort of, quick nav might change what events are sent to the application

<michael_fairchild> Matt: bottom line is that assertions should say something about what screen readers should do

<michael_fairchild> Jon: so it doesn't really matter if you are on a focusable or unfocusable element before you navigate to the target element. It just ensures that the screen reader switches to forms mode.

<michael_fairchild> Matt: we usually use 'reading mode' and 'interactive mode' in APG as generic terms

<michael_fairchild> Matt: each assertion should start with what mode is expected to start with

<mck> scribe: matt

<jongund> Corbb: Is there a good IRC client for screen readers

<jongund> Matt: ChatZilla is good client, there is a standalone version, works best with NVDA, but also Jaws

<jongund> http://chatzilla.rdmsoft.com/xulrunner/

<jongund> Matt: This is really fantastic, was our discussion helpful, any other feedback you would like?

<jongund> Yphta: When keyboard focus was on a menu item that was disabled, was announced as unavailable, so there are some differences, would that pass?

<jongund> Yohta:It should say disabled

<jongund> Matt: When something is disabled and focusable, is aria-disabled reported, so we want s specific assertion for aria--disabled

<jongund> Michael: You wer going to mark it as a partial result?

<jongund> Yohta: I was not sure how I should mark it

<jongund> Matt: If they don't do anything, that should be a fail, it should automatically announce the disable dstate

<jongund> matt: Obviously this will not only happen, if you are in interactive mode, and the example does not support moving focus to the disabled element, then the test doesn't apply, but if it does allow to move focus it should

<jongund> michael: the aria-disabled starts must be conveyed

<jongund> matt: all assetions will be that way

<jongund> matt: if JAWS normally says unavailable, it should be consistent in our assertions

<jongund> matt: we need to know and document what screen readers do for accessibility API mappings

<jongund> yohta: as long as each AT is internally consistent then it passes

<jongund> matt: let's say something is not focusable, and has aria-disabled, it would apply in reading mode

<jongund> michael: we have 20 minutes left

<jongund> matt: let's talk breifly about gird with jaws

GIRD Exploration

<mck> Wiki page where I'm exploring how I'd test grid with JAWS:

<mck> https://github.com/w3c/aria-at/wiki/Exploratory-Test-of-Layout-Grid-Example-1

GRID Exploratoin by Matt King

<jongund> matt: I was just looking how I would approach testing

<jongund> matt; I started by looking at the roles, properties table, but it didn't seem to work that way

<jongund> matt: So i did my normal exploration, first reading mode and then interactive mode

<jongund> matt: So what we are testing is user actions, interactive and reading mode

<jongund> matt: my list is not exhaustive

<jongund> matt: I looked at the heading levels, and I have reading mode tests and interactive mode tests

<jongund> matt: I tried to break down the reading mode actions like read next element, read current element

<jongund> matt: In interactive mode we need to do every single keyboard command, plus TAB since it is not listed

<jongund> matt: we would have current element commands

<jongund> matt: in voice over there might be help cpmmands

<jongund> matt: for every element which screen reader commands should be tested in each modes

<jongund> matt: then you need to make multiple assertions

<jongund> matt: just navigating elements, you will get roles, preprties and states, and this is where the example role, property and state information comes in

<jongund> matt: this should help create a pretty comprehensive set of assertions

<jongund> matt: The commands are screen reader centric, eg.s reading mode, interactive mode

<jongund> matt: how do we want to disambiguate things with our assertions

<jongund> matt: the bigger thing is how do we develop the approach to testing, and how do we come up with all the tests...

<jongund> matt: we need both screen reader commands and the widget commands for each widget

<jongund> matt; we have to include labels, implied roles, properties and states

<jongund> michael: I think this is an amazing approach, but this will take a lot of time

<jongund> michael: what should the priority speed or comprehensiveness

<jongund> matt: we might want to start with most common commands, even though that sounds pretty soft

<jongund> matt: It doesn't matter if we are complete, but we will get feedback from people to fill in missing assertions

<jongund> matt: if we don't have an initial command, someone will probably help us identify one

<jongund> michael: That satisfies my concerns for now

<jongund> matt: any other commets

<jongund> seth: Is there something that has meet used before, where we can start

<jongund> seth: Is there something that siteimprove would like to allow

<jongund> seth: is siteimprove still on the call

<jongund> matt: John is still in the meeting, but maybe muted

<jongund> matt: To some extent we are testing the assistive technology users

<jongund> matt: there is not enough meat on the bones to ask them yet

<jongund> seth: being a tester using automated tools and then using a screen reader and not having the understanding of the screen reader, what seems acceptable to me, may not be acceptable to a screen reader user

<jongund> matt: I totally hear you

<jongund> matt: let's talk about what would help people to contibute

<jongund> matt: I am struggling to figure our how to integrate asynchronous contirbutions, any ideas

<jongund> john: I am from webaim, I would like to help contribute

<jongund> matt: part of what we are doing is figure out an approach. once we have an approach then there will be a ton of work

<jongund> matt: we need to figure out that list of tests, michael had some ideas about automate test generation

<jongund> matt: let's put that onthe agenda for next week

<jongund> matt: yohta and I are working on assertions and hopefully we can identify what we need

<jongund> john: i think so

<shimizuyohta> jongund: Yohta and Mr.Gunderson will meet tomorrow 11am.

<shimizuyohta> I mean 10am

<jongund> jongund: I will send a meeting notice about yohta and my meeting tomorrow

<jongund> matt: right now we are just talking ti out help us out

<jongund> matt: we could also have another meeting time

<jongund> michael: Ask people on the list to review discussion topics

<jongund> matt: we can do that when we have enough, what

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 Jemma_ michael_fairchild Seth Kovanic Yohta shadi jongund SethKovanic
Found Scribe: mf
Found Scribe: Matt
Found Scribe: mf
Found Scribe: matt

WARNING: 0 scribe lines found (out of 127 total lines.)
Are you sure you specified a correct ScribeNick?

Scribes: mf, Matt

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