<Jean-Francois_Hector> Our use cases Google document: https://docs.google.com/document/d/1c81otH0MP79qGPjOFH06LCKT_4STaqNNExAd9OmvcWs/edit?usp=sharing
<scribe> scribe: MF
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
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.
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]