W3C

- DRAFT -

ARIA and Assistive Technologies Community Group Teleconference

17 Apr 2019

Attendees

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

Contents


<michael_fairchild> scribe: MF

<michael_fairchild> Matt: JF - how much information do you want to capture in this activity?

<Jean-Francois_Hector> Here's the Google Doc link: https://docs.google.com/document/d/1HteU9qUBNVfCr2EI5u9oWInEB15jNQb-Kmr8yFQvdC4/edit?usp=sharing

<michael_fairchild> JF: as much as possible, in IRC and in a google doc

<michael_fairchild> Matt: I'll scribe, but we will want to capture what is in the google doc and put it into the wiki at some point.

Intro to use case development process

Correction - First topic is Yota's porgress on prototyping process

Yota: has developed assertions for jaws/chrome and firefox
... do we want assertions shared multiple screen readers, e.g., current line

MF: was envisioning more generic command assertions and test the assertion in multiple ways.
... a line in the doc for each combination of assertion and command

Discussion of whether the assertion contains the command or reference to the screen reader command; leaning toward the idea that it would not.

Intro to Use Case analysis

jf: important to focus on most typical use cases

We want to stay on use case topic at a high level and not get into weeds.

<Jean-Francois_Hector> https://docs.google.com/document/d/1HteU9qUBNVfCr2EI5u9oWInEB15jNQb-Kmr8yFQvdC4/edit?usp=sharing

Google doc ahs format of exercise and questions for the group.

Summarizes agenda for exercise

Starts with 5 minute description of format and goals then to main part of exercise.

Methodology called jobs to be done.

<michael_fairchild> I'm reconnecting to the call

Focus on user needs without making reference to implementation.

Defining problem with out describing solution

<michael_fairchild> For folks that just joined, this is the document that are referencing: https://docs.google.com/document/d/1HteU9qUBNVfCr2EI5u9oWInEB15jNQb-Kmr8yFQvdC4/edit?usp=sharing

Slightly different from how use cases are sometimes defined.

Try to focus on most typical use cases because there are so many possibilities.

format and goals for exercise

JF: who is going to be using this tool?

Web developers, AT developers, browser developers, A11y consultants, teachers, students

jg: Maybe lawyers
... probably not a core group

jf: what is the tool going to allow people to do

mf: Find out what aria roles/states/props work or do not work in a screen reader browser combination

Sina: how they work

mk: How they work in real life

jg: Help people understand the usability of a way of using aria

jf: find what aria attributes work and what expected output is

SR dev: where am I weak, where are bugs, how can i improve my support.

web dev: what can i use to give a great experience?

Sina: web dev: Is my implementation of a pattern correct

Understanding real situations and struggles and desired outcomes

jf: User situation: web dev has done code and not working way expected and may be confused. Not sure where problem is.

Desired outcome: feeling reassured that they know how to do things because bug or problem is expected.

<Wilco> True, and its effectively the same use cases as the dev

Wilco: another actor could be a tool developer, e.g., automated test tool

jf: situation: I'm a web dev, and I want to know how timplement a pattern. I've read the pattern, should I do it that way? Probably a sense that this is complicated.
... Desired outcome: web developer can grasp the essence of what needs to be conveyed to assistive technology users

Desired outcome: you have confidence to identify what parts of your implementation are correct and what parts are not correct.

jf: can continue next week. Really want to focus on understanding the painpoint we want to resolve.

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/04/17 17:00:46 $

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 Yohta Michael Fairchild Jean-Francois_Hector jongund
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: 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]