W3C

- DRAFT -

Accessibility Guidelines Working Group Teleconference

03 Aug 2017

See also: IRC log

Attendees

Present
AWK, Rachael, Kathy, Joshue108, JF, shadi, MikeGower, david-macdonald, KimD, alastairc
Regrets
Chair
AWK
Scribe
Kathy, Rachael

Contents


<AWK> +AWK

<Kathy> scribe: Kathy

keeping comments brief

Andrew: please keep comments brief

Plain Language: https://www.w3.org/2002/09/wbs/35422/sc_august2017 (only item 2)

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

<lisa> https://www.google.co.il/search?client=firefox-b-ab&q=core+vocabulary+french&spell=1&sa=X&ved=0ahUKEwj_3uqysrvVAhXKAMAKHXMuAM4QvwUIISgA&biw=1366&bih=657

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.

Concurrent Input Methods:https://www.w3.org/2002/09/wbs/35422/MATFSC_june/results (item 3 only)

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

Summary of Action Items

Summary of Resolutions

  1. No consensus yet.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/08/03 16:58:01 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]