<michael_fairchild> scribe: mf

agenda

<michael_fairchild> matt: I didn't get enough work done on the checkbox example. It might be better to talk about that next week.

<michael_fairchild> matt: we could dive into a11ysupport data model details

<michael_fairchild> matt: we could think about what is in Yohta's spreadsheets and compare that the a11ysupport structure

<michael_fairchild> Yohta: I'd like to discuss my updates to the menubar spreadsheet

Yohta's updates to the menubar spreadsheet (assertions)

<michael_fairchild> Yohta: One concern that I had is that in forms mode, a single thing might have 4 different assertions (role, name, property, etc)

<michael_fairchild> Yohta: this creates a really long and verbose document

<michael_fairchild> Matt: my perspective: I'm thinking ahead to how we will score things. Since role, label, posinset, and setsize are all different things that might not be individually supported, we need to track them separately.

<michael_fairchild> Yohta: yes, that makes sense

<michael_fairchild> Matt: for example, if it does 3 our of 4 things, that one difference is important. Mixing them would be unclear. They need to be atomic.

<michael_fairchild> Yohta: that makes sense to me. I'm glad to hear that I was on the right track

<michael_fairchild> Michael: I agree.

<michael_fairchild> Michael: it is a lot of information to collect and read, but it is necessary

<michael_fairchild> Matt: I'm imagining that we will build a user interface to help with streamlining collecting information.

<michael_fairchild> Matt: an interaction command followed by a list of assertions that should be met for that command, followed by radio buttons (or whatever) to collect support information for each of those assertions

<michael_fairchild> Michael: this is a weakness of a11ysupport.io right now: its hard to collect data in a streamlines way. More on that later.

<michael_fairchild> Matt: any other questions, Yohta?

<michael_fairchild> Yohta: I'm working on a more comprehensive version which should be ready in a few weeks

<michael_fairchild> Matt: this looks really good so far. I'm really happy with how this is shaping up.

<michael_fairchild> Matt: I'm wondering about how we capture what the user is doing (open a submenu from a menu item) and how (space, enter, arrow)

<michael_fairchild> Matt: maybe this is less important in interaction mode (commands that are owned by the webpage), but commands that are executed by the screen reader are more important. Perhaps we have a common set of assertions that are for commands that are shared by many screen readers (such as the say current item command)

<michael_fairchild> Matt: So i'm wondering if there should be a column for a test name, then a column for the command name

<michael_fairchild> Matt: and then the assertion

<michael_fairchild> JF: why is it important to have both for each line? Will AT provide different results, or does that tester want to know the command to test?

<michael_fairchild> Matt: it's the second one. How a test is performed.

<michael_fairchild> JF: we could use a note to track that or something else to track that.

<michael_fairchild> Matt: yep, the spreadsheets temporary

a11ysupport data model

https://a11ysupport.io/

mf: created an arch document

<michael_fairchild> https://github.com/accessibilitysupported/a11ysupport.io/blob/master/documentation/architecture.md

plan to create a diff between thi data model and aria-at spreadsheets.

didn't get that afar yet.

Describes grading method, file structure, data model of json, and the info captured in that model, and methods for populating it, and how front end is built.

Model is divided into separate tables for technology features and tests for tracking if a specific feature is supported.

Technologies are html, svg, etc.

Diff technologies have diff directories, e.g., aria is /tech/aria

For a secific feature, it has its own file.

ex: file for aria-haspopup.

Fields in the file describe the feature, e.g., title, type (role/state/prop) short description, related issues, links to standards, e.g., specs

Related issue would be like an NVDA bug.

Related issues are not capturing failures of a test.

This file is metadata about the tech feature, not info about the support for the feature.

Now going into test object.

tests/tech/aria/feature-name.json contains tests for feature-name.

This file contains an array for features that are tested. In practice this is length 1 array.

Type describes whether custom or assertion, at this point only have assertions. there can be only one.

Description is a md string.

Flag for screen reader testing, and a flag for voice control.

Key decision: the same test can apply to multiple assistive technologies.

prop for html file that contains the test case.

CSS target for test that is a CSS selector that is used to identify which elements in the html file that to which test applies.

Assertion object describes the assertion.

History array describes how the test has been updated over time.

Results object describes the results of a specific run for an browser/at test run.

Documents the commands used to execute a test.

Discussed approach to simplification. How do we balance simplicity with flexibility.

This model is not well optimized for collecting data, but works well for aggregating results for presentation.

jf: discussing both use cases and pain points could help

<michael_fairchild> https://github.com/w3c/aria-at/wiki

https://github.com/w3c/aria-at/wiki/Background

http://a11y.pro/csun2019/

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: michael_fairchild shimizuyohta Matt-King Jean-Francois_Hector
No ScribeNick specified.  Guessing ScribeNick: mck
Found Scribe: mf

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