See also: IRC log
<AWK> +AWK
<Kathy> scribe: Kathy
Andrew: please keep comments brief
Andrew - we have discussed this one before
Lisa - some things that changed, we removed double negatives, we addressed the international concerns and concrete language
scribe: we could reduce scope but for AAA feel that it is ok
scribe: common words are core
vocabularies and exists in all languages
... these are public
<lisa> https://github.com/w3c/wcag21/issues/30
scribe: issue 30 for single A we
have some scripts to generate a core vocabularity
... there will be a place to generate if it is not
available
<marcjohlic> I heard AAA mentioned, but the text shows A - is this still being proposed for A or AAA now? (Or are there two proposals)
<lisa> should be AAA
<marcjohlic> Thanks
Andrew - while I did change the survey to say AAA, the github version still says A but it is AAA
JF - there is a strong linkage between this SC and controls personalization
scribe: we are looking at fixed
taxonomy
... not clear how this would be provided to the site. We need a
linkage of that list to the SC. Just because it is out there is
not enough
<AWK> AWK updated in Github to AAA
scribe: we need the word list to
be programmatically linked to the site
... this may be just wordsmithing
Lisa - do you think this needs to in the SC
JF - yes
Alastair - was going to suggest the opposite to remove the latter part. At AAA we can have some subjectivity
scribe: do we really need it
Lisa - happy with either way
Mike - echo that, there is no clear correlation between common word list and simple and clear terminology
Lisa - people don't always know the clearest word
John - if we water this down too much we will not have anything
scribe: what we want is a linked definition of those words and phrases
Lisa - it is complicated going in that direction
scribe: the definitions are not
always in the lit
... it is a word that people have learned
... if you have the definition then people will be using it in
the correct way. It is for the author not the user
... that the author is using it in the right context
... we said provide words then we can have a plug in that will
replace the words
JF - what is the difference in this to personalization
Lisa - this is one way to satisfy personalization
scribe: we have limited scope in personalization
<alastairc> @JF - personalisation is different in scope of what it's on (controls etc), and intent of the change (visible text).
AWK - we saying all we need is a list of the words. The definitions are not needed
scribe: what we should have is a explicit link to the term
Lisa - could go either way
JF - how do we know what public list
Lisa - we need to identify it and put in conformance statement
Alex - remind WCAG 2.0 needs to be testable for all levels
<JF> +1 to Alex
Lisa - then that is an argument to have a linked list
Mike - look at 2.4.6, how is that tested
Alex - doesn't say how descriptive it needs to be
<gowerm> Clear Instructions: Instructions describe the topic or purpose.
Mike - clear instructions is an ok way to test; so go with the same language for this SC
JF - Alex is right, this needs to be testable. Introducing "common" and it is ambigous
scribe: for heading and labels we
are not talking about what is descriptive. We cannot fail if a
heading or label is there
... there are multiple common lists there. How do we know which
one it is
... how do I test based on the public list
<lisa> Use the most common 1500 words or phrases or, provide words, phrases or abbreviations that are the most-common form to refer to the concept in the identified context.
Lisa - we have gone through a number of iterations
<AWK> Perhaps "Provide common words, phrases, or abbreviations that are identified on a linked public word frequency list when possible"
scribe: if that is the only
issue, then we should reword the bullet point to make it
testable
... are there other issues
<AWK> Perhaps "Provide common words, phrases, or abbreviations that are identified on a linked public word frequency list unless terms needed for comprehension are not available on a list"
Jason - frequency list means a list of words and phrases based on frequency in a sample of text and then order them
<lisa> deffinition is at https://rawgit.com/w3c/wcag21/plain-language-minimum_ISSUE-30/guidelines/terms/21/identified-context.html
scribe: there will be common words for each language because they are part of the grammar but it is dependent on the sample
<lisa> Word lists by frequency are lists of a language's words grouped by frequency of occurrence within some given text corpus from the same context. Examples of a context include a dialect, subject matter or profession. A word frequency list has to be generated from at least 1000 sources from the same context although 50,000 sources is recommended . the word frequency list and he context should...
<lisa> ...be identified in the sites meta data, or in an accessibility statement or by some other known technique.
scribe: the list doesn't have to
meet any requirements
... that is an essential part
<Rachael> scribe: Rachael
Lisa: Jason, did you see the definition?
Jason: yes
Lisa: The definition of what the corpus needs to be.
<JF> +1 to Jason
Jason: There may not be a strong correlation between being on the list and what users area likely to know. Its a complicated problem and I don't think we'll solve it in a hurry.
Lisa: We've been working on it for three years, so not in a hurry. The evidence that this will have impact is hard to dispute but what I'd like to do is try to bring Jason, John and others who are unhappy with this together on a call to reach consensus on wording. \
<lisa> thanks John\
<KimD> +1 "word frequency" not helpful
John: I'm happy to help with
this. I don't think we are solving the problem with a word
frequency list. You give an example of the word mode. I argue
that mode will be on frequency lists because it is used
frequency. It was unclear how it was being used. It isn't about
frequency of use. Its about making sure users understand what
the words used mean.
... I think we want to make sure users understand how to
interact with controls. I don't think common words will solve
that problem.
AWK: If you would like to participate in that conversation, contact Lisa.
RESOLUTION: No consensus yet.
AWK: Number 2 in this survey. Very mixed responses. Core issue: question around whether this was specific to users with disabilities and what use cases highlight that
<AWK> Issue: https://github.com/w3c/wcag21/issues/64
<trackbot> Created ISSUE-50 - Https://github.com/w3c/wcag21/issues/64. Please complete additional details at <http://www.w3.org/WAI/GL/track/issues/50/edit>.
<Kim> https://github.com/w3c/wcag21/issues/64
<AWK> current text: https://rawgit.com/w3c/wcag21/concurrent-input-mechanisms_ISSUE-64/guidelines/sc/21/concurrent-input-mechanisms.html
Kim: I think there were 3 things.
There are three use cases in the link provided. There are two
other issues.
... One was scope, so we fixed that. See current language. And
testability was the final issue.
Chris: Testability issue: We have
concurrent input mechanisms. We want to be able to suppor input
mechansim A-C but how do we support a combination? I think if
you support the individual mechanisms then the user agent
should adderss the switch.
... The content author would support the individual input
mechanisms only. If a failure occurs in combination,then its a
user agent or operating system failure.
Kim: We switched the wording back based on previous conversation. We are not restricting it. We do have the security exception included.
AWK: What are a couple of use cases?
Kim: 2.1.1 covers keyboard
access.So we can switch to keyboard access but we may not be
able to switch to touch. This use case should allow user to
switch to touch or go from mouse to touch and touch to
keyboard.
... You can restrict to touch only in mobile. This does happen,
I hit it on a client site yesterday.
Chris: There are two other use cases. I use speach to interact and if I run into a situation where I can't use speech and touch its an issue (There is a known issue in MACs that isn't web but exists).
The third use case is when you can't get keyboard focus, you can use the mouse so one use case is the need to fallback on the mouse.
Sometimes we need to fall back when something fails, so adding another restriction on the fallbacks creates an issue.
David: I agree people switch modalities. I do myself all the time. We've narrowed the scope but I don't understand how we reconcile what the failure techniques? What are the dumb things authors do to cause this?
Kim: This is anything you can do in keyboard but not in touch.
David: Are we saying the author has to actively ensure it works with keyboard and touch?
MikeG: How is someone supposed to
test this? I unplug my headset and it stops playing. How does
the tester know if its a hardware, OS, or site issue?
... If you put in a headset, its not smooth. When does it stop
supporting? Is this even relevant?
Kim: We aren't saying you have to test it with all combinations. We are just saying you haven't restricted it by for example, using only touch or using only keyboard
MikeG: You are going to fail things if they are only can be done by keyboard?
Kim: yes, that would fail.
John: How do I know?
<AWK> "Web pages do not restrict user input modalities available on a platform. Exception for security or essential nature of activity"
John: I don't know what the users using. How do I know? WE have a long standing requirements that at a minimum you must be able to use the keyboard. Its one of our first tests. Now you say that if they can get through with hte keyboard, you're going to fail it?
I agree we need to support additional modes but failing something because only a keyboard can be used seems problematic.
Alex: Is there a reason why there is no essential exception here? If the particular functionality of a page is to record audio, you need a microphone.
Kim: WE added that exception from the last call.
Alex: Looking at wrong text.
AWK: WE will link ot the text to ensure it is only in one place. Its caused more issues than solving.
Alex: #2 Can you put in IRC a link of a website with a gregious violation of this and tell us how it fails?
Kim: Nothing I can share
publicly
... We can provide a list or create examples. We didn't link to
exact code.
Alex: I think you should at least create one.
<JF> "support multiple forms of input / do not block alternative forms of input" (???)
<gowerm> I think the use of "is not restricted by the content" provides the language we need to constrain this.
<JF> +1 Mike
Kim: Keyboard is not the primary
input anymore. Saying that all we require is keyboard I find
problematic. There is a lot of concern around touch so we
created an SC that says you need to support multiple modalities
to address this.
... This is an attempt to integrate a fix
Jason: I'm looking at this and
probably should rewrite the survey comments. IT says
nonrestricted - is that meant to be more than preventive? Just
looking at the clauses, it seems hard to find a really serious
issue that this addresses which is not a user agent or
operating system issue
... It isn't clear what it is trying to resolve. Its tightly
written and specified which is good but hte lack of clarity is
challenging.
<AWK> Web pages do not restrict user input modalities available on a platform. Exception for security or essential nature of activity
AWK: I had put in some language that may solve hte problem or take us back. Would it help to say "Web pages do not restrict user input modalities available on a platform. Exception for security or essential nature of activity" ad then add restrictions or exceptions.
<JF> +1 to Andrew
I think we still have the issue of having good examples.
<Zakim> AWK, you wanted to say that if adopting this we would want to change "action" to functionality and allow for slightly different processes to achieve a common end point and to
AWK: Is it endless? How would you undermine this goal using scripting on web/mobile, how many modalities can you shut down?
David: I think you language is more in keeping in whether the author has done a dumb thing. The other thing is do we want to have a success criteria requiring pointer? We decided not to pursue this but I think you are saying everything should work with pointer and with voice.
<Kathy> Web pages do not restrict user input modalities available on a platform unless it would jeopardize the security of the content or invalidate the action.
I don't think we have time to address the pointer issue.
<gowerm> +1
JF: Agree with Kathy's suggestoin "Web pages do not restrict user input modalities available on a platform unless it would jeopardize the security of the content or invalidate the action."
David: Yes
<Kim> +1
<shadi> +1
<Alex> still need to see an example
<david-macdonald> Web pages do not ACTIVELY restrict...
AWK: I would want to look at it more but yeah. I think the advantage is that we are thinking about current modalities but this has a certain amount of future proofing as well.
david: add actively "Web pages do not actively restrict user input modalities available on a platform unless it would jeopardize the security of the content or invalidate the action."
<lisa> will thins include blaocking web extentions?
AWK: Lets play with the language
a little on the list. We are close. People are already dropping
off.
... I can stay to wordsmith but we can't decide to CFC after
call is closed.
Kathy: Wording has been updated.
<david-macdonald> Web content does not restrict user input modalities available on a platform unless it would jeopardize the security of the content or invalidate the action.
<AWK> Web pages do not prevent use of any user input modalities available on a platform. Exception ...
<david-macdonald> Web content does not prevent ...
<david-macdonald> Web content instead of web page could help
<AWK> The page is the evaluation unit though
<AWK> "Web pages do not prevent use of any user input modalities available on a platform"
<Kathy> Web content does not restrict user input modalities available on a platform unless it would jeopardize the security of the content, invalidate the action, or override a user setting
<Kathy> Web content does not restrict user input modalities available on a platform unless it would jeopardize the security of the content, invalidate an activity, or override a user setting.
<Joshue108> how about "Web pages do not prevent user input modalities available on a platform"
<Joshue108> -q
<Joshue108> Sorry, I see Kathy has made a change like that..
<JF> As a User with comprehension issues associated to language (terms and usage), I require the ability to: a) easily determine or get the definion of terms and words used on 'critical' (conventional?) controls and inputs (AA) b) easily find or access extended help explanations for inputs, controls and error messages (AAA) c) convert common terms and instructions to other modes of expression (eg. convert form control labels to symbols) (AAA) Techniques: All techni
<david-macdonald> All functionality requiring specific device sensor information can be operated with pointer, unless the device sensor is essential for the function and not using it would invalidate the activity.
<AWK> trackbot, end meeting
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Default Present: AWK, Rachael, Kathy, Joshue108, JF, shadi, MikeGower, david-macdonald, KimD, alastairc Present: AWK Rachael Kathy Joshue108 JF shadi MikeGower david-macdonald KimD alastairc Found Scribe: Kathy Inferring ScribeNick: Kathy Found Scribe: Rachael Inferring ScribeNick: Rachael Scribes: Kathy, Rachael ScribeNicks: Kathy, Rachael Found Date: 03 Aug 2017 Guessing minutes URL: http://www.w3.org/2017/08/03-ag-minutes.html People with action items:[End of scribe.perl diagnostic output]