W3C

- DRAFT -

ARIA and Assistive Technologies Community Group Telecon

08 May 2019

Attendees

Present
Matt-King, Michael, Fairchild, Yohta, Jean-Francois_Hector, jongund
Regrets
Chair
Matt King
Scribe
MF

Contents


<Jean-Francois_Hector> Our use cases Google document: https://docs.google.com/document/d/1c81otH0MP79qGPjOFH06LCKT_4STaqNNExAd9OmvcWs/edit?usp=sharing

<scribe> scribe: MF

Update from Yota on prototype work

Yohta: I'm still working on more assertions menubar and hope to have that complete by the end of the week.

mck: we also talked about testing a simple example, so if you are going to move on to another, perhaps the checkbox would be a good option.

<Jean-Francois_Hector> Our use cases Google document: https://docs.google.com/document/d/1c81otH0MP79qGPjOFH06LCKT_4STaqNNExAd9OmvcWs/edit?usp=sharing

use-case for contributors

discussion around different types of contributors, such as someone who contributes test results, someone who vets test results, someone who contributes code, someone who contributes documentation, someone who contributes feedback or issues around published data, etc

JF: how many people do you image will contribute to the project?

mck: ideally a lot, but I'd be happy with 10 to start

jf: for the project to be a success, how many people need to contribute test results?

mck: probably 10 to 20 for the core results
... to cover the breadth of the possible at/browser combinations, we would need many more people.

Jon: for this to be truly successful, we would need to get the community involved and educate them. Possibly events at popular conferences, hackathons, etc

JF: I see two types of contributors: 1) people to create the tests, 2) people to run the tests

mck: vetting and reviewing is important too

jf: I have that too
... What is the most important aspect of the project to finish first, so that contributors can start to get involved?

mck: test cases and procedures

JF: why would someone who could contribute bother to do it?

mck: a driver might be frustration with assistive technology. They just want it to work.
... they might be users of assistive tech, or might need to support users of assistive tech in some way

Jon: there are a lot of folks that want to learn how ARIA and assistive technologies are supposed to work
... one of my motivations is to help support the standards, and get closer to the ideal of the original web

mck: a screen reader developer who is worried about the reputation of their software

JF: one thing that motivates me - specs and aria practices often don't match up with reality
... so its hard to learn
... its so hard to learn what the expectations are and what current support is. I just want to make something that works.

Jon: that matches my view point too. questions of support and expectations are very common in discussion lists

mck: exactly. its nearly impossible for a developer to get a great and straight answer as to the best way to code something. There is just so much inaccurate and incomplete information out there.

Jon: I think this project will help people understand how markup affects the experience of screen reader users

JF: what are some situations in which someone is struggling and us doing some testing would help them out. For example, when I think I notice a bug, I find it painful to not share that knowledge.

Jon: if I'm building a specific widget, and now I'm testing it, and I'm not sure about what screen reader behavior is expected, I might be to go to the project and find out what those expectations and then contribute results

(that was mck, not Jon)

JF: contributing test results is probably easier than contributing assertions

mck: yes

<shimizuyohta> I need to excuse myself now, but these conversation were very enlightening JF, thanks!

JF: if I want to build a good experience, I either have to study the quirks of screen reader support for potentially years, or use an existing resource. This project is that resource

mck: a tester might also want to move the industry forward by contributing rather than testing in isolation.
... there is a validation aspect too.
... Jon do you ever see yourself organizing a class project to do testing and contribute results?

Jon: yeah, and that is one thing I'd like to start doing
... could also be part of the Teach Access project
... a lot of the academic work is focused on building new technologies rather than working on the existing technology

JF: I'll work on creating use-cases for contributors using this discussion.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/05/08 17:02:04 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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 Michael Fairchild Yohta Jean-Francois_Hector jongund
No ScribeNick specified.  Guessing ScribeNick: michael_fairchild
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.)


[End of scribe.perl diagnostic output]