<scribe> scribe: mf
matt_king: I think I was
combining two different topics here.
... one topic is how we write sr instructions
... when I was writing expectations, I was struggling with the
vocabulary to use. words like 'read', 'operate', 'convey',
'navigate', 'understand', etc.
... I think we need a really limited vocabulary so that it is
very clear what exactly the expectation is.
... I also wonder if I'm blending screen reader behavior and
screen reader behavior. It might be good to keep these concepts
separate.
... menu example: when using arrow keys to navigate within the
menu, are you reading the menu, navigating the menu, or both?
Do we need a different word when in reading mode vs interaction
mode? These are really two different operations and can have
different expectations associated with them.
... for example, boundaries would be conveyed in interaction
mode, but perhaps not in reading mode.
... other way around
... in interaction mode, you will also often hear posinset
information, but perhaps not in reading mode
... so maybe 'navigate' just means you are moving a cursor and
we define each mode in addition to the word 'navigate'
Example: task - read navigation region; expectation: region role, name, and boundaries are announced.
matt_king: there are many
different ways to get to a landmark region. You can get into
one in either reading or forms mode. The expectations are
different in both. In forms mode, you might be aware that you
crossed a boundary but you might not be aware where that
boundary is.
... in this version, I used the word 'read' whenever we were in
reading mode. But that's confusing because you can read the
current line/position/etc without changing the cursor position.
You can also read by navigating.
Yohta: my initial thought is to describe the vocab in written text
matt_king: if you change the
state of the checkbox, you are operating the checkbox.
... discussed different ways to 'operate' menu items, via
screen reader shortcuts and non-screen reader commands
... do we need different verbs for those?
<Matt_King> mf: how detailed should the data collect be? there are so many possibilities for output.
<Matt_King> mf: If we are too detailed, it could slow everything down too much.
<Matt_King> mf: Perhaps not our responsibility to be that detailed.
<Matt_King> mf: How do we get the most value for effort? 80/20 rule that we should apply? 80% coverage with only 20% of the commands?
<Matt_King> jg: We need to capture the effect of the aria markup.
<Matt_King> jg: if some of the aria is not exposed that is important to user, we need to capture that
<Matt_King> jg: difference between modes is kind of fuzzy
<Matt_King> jg: Compare VO and JAWS
matt_king: if we have different
meaning for 'read', 'navigate', and 'operate', I want to make
sure we are all on the same page.
... combobox example - when number of suggestions changes, the
screen reader user is 'informed' of the change.
jg: have you thought of the word
'action'?
... navigate is usually tab key or arrow keys, and, read is
command to read current item/position, operate (or activate) is
usually space, enter, or click.
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 shimizuyohta michael_fairchild 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: 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]