Web Content Accessibility Guidelines Working Group Teleconference -- 19 Sep 2016

<AWK> +AWK

<jeanne> scribenick: jeanne

<kirkwood> +kirkwood

<Joshue108_> + Joshue108_

<AWK> +AWK

<mhakkinen> + mhakkinen

JO: welcome

[Introduction]

Introductions

Review COGA SC Proposals

AWK: This is the first time we have looked at specific success criteria proposals.
... great work from the Task Forces, we have items to review

Lisa: Everyone here knows about learning disabilites

[presentation from Lisa]

Lisa: Conditions
... many different conditions, that are largely groups of symptoms
... memory
... reading text
... familiarity with symbols (math)
... familiarity with user interface
... problem solving
... keeping focus
... computation
... executive function

JO: Interesting article from BBC on dweveloping executive function in children
... people can be extremely intelligent, but can't deal with a specific access to a particular function
... with Internet of Things, apps are everywhere and growing. If you can't figure out the app to turn on your heat, you can't live alone.
... much of the research is behind a paywall. Very expensive to find the right research. You have to pay even if the research is useless.
... we are trying to look at the broader view
... Undeclared (cognitive) disabilities awareness
... People with cognitive disabilities hide it, especially in the workplace.
... The need is still there
... lots of pieces need to come together
... Phased approach -- started with 8 different disabilities
... what we found, is that we are getting a lot of overlap, which is a very good sign
... then we compiled a document of the user research
... a member of the task force had access to the university research
... people wrote key findings of the research and put it in the public space
... next we compiled issue papers. They brought a broader perspective, such as security. For people with memory issues, passwords are very difficult, whcih blocks the user from online banking
... we looked at the problems, and then started looking at the solutions.
... we made a list of authoring techniques -- common ideas and strategies that people were using.
... we found authoring techniques that helped both people with dyslexia and downs syndrome -- so we knew we were on the right track with that issue.

Lisa: flowchart
... user research and issues papers feed
... Gap Analussis and Roadmap that feed
... W3C initiatives (list of groups)
... The Roadmap influences more working groups and efforts
... User Research document
... Issue papers
... Gap Analysis and Roadmap
... Roadmap
... table of User Needs, proposed success criteria, authoring techniques needed, proposed new semantics, personalization, and operating system level
... Then there is a document on semantics, which would be used like ARIA. That makes some of the success criteria less burdensome.
... people won't be interested in semantics unless there is an author burden

JO: Can we add a label in Github for the success criteria, can we add a line to reference that it has new semantics

AWK: Something that can't be able to be done today, should be considered for the Silver timeframe.

<Joshue108_> +1 to AWK

Lisa: We have a draft of new semantics that ARIA WG is taking up this week.

MC: The semantics won't have a big impact until they are taken up.

Lisa: IBM wants to take up promoting the semantic uptake as an open source project
... people can use it if they want to

Kathy: Assistive technology may not be taken up

Lisa: that is an interesting space, things have varied uptake

<mhakkinen> +q

Kathy: [example] people with dementia have assistive technology, which they may or may not use

<Joshue108_> Good to hear that AT vendors are involved in the COGA work.

Lisa: People are using personalization settings for a reminder system, for example. Assistive technology in COGA are apps.
... a lot of it is in education

MH: Have you looked at the Acccommodation Guides and Guidelines from US govt?

Lisa: Example: people who have distraction, that they have an app that automatically hides all the other apps and notification, and restores them at the end of the meeting

<Joshue108_> https://github.com/w3c/wcag21/issues/7

<Lisa_Seeman> https://rawgit.com/w3c/coga/master/extension/3-1.html

"Small" change to 3.1

<mhakkinen> There are two documents that I will quickly provide reference to. They are from two different consortia of US states and designed for student assessment:

<mhakkinen> http://www.smarterbalanced.org/wp-content/uploads/2015/09/Usability-Accessibility-Accommodations-Guidelines.pdf

AWK: modification of the guideline, rather than an SC.

<mhakkinen> http://www.parcconline.org/assessments/accessibility/manual

AWK: the proposal is the remove the word "text". COntent needs to be understandable, whether is it text, video, and audio

Lisa: I thought about changing "readable" to "understandable", but didn't propose it.

James: Isn't there a guideline about symbols -- or at least there should be? Should the symbols part be in a different place

Michael: Are the guidelines specific to text and what would be impacted by the change.
... the success criteria are very text specific. We are losing focus by this proposal.
... I'm trying to address it as a way of thinking -- not as a critique of the proposal.
... we can create new guideline

<David_macdonald> Make text readable and content understandable?

LIsa: Breaking things into manageable blocks of content. This particularly is a problem for long presentations -- putting in bookmarks
... we need a new guideline

Kathy: I think you should have new guideline. That is what Mobile is doing.

<Zakim> AWK_, you wanted to say that this change may be impossible to evaluate without seeing the SC that might fall underneath it

Joshue: I'm not really sold on change, and would prefer to see what all the success criteria under it need to do

AWK: Let's table this item until we see the success criteria.

Michael: Guidelines are organizational units, so we should address them later when we know what we are organizing

David: When we first were writing WCAG, we thought it would be a large guideline, but the testability narrowed it down

Joahue: What Lisa is doing, is tapping into that.

John: What Lisa is proposing is all about language

<David_macdonald> Welcome Rich

John: a guideline about Understandable Structure.

Lisa: I'm good with that

[group agrees to table discussion]

Alastair: We are working with a jigsaw puzzle, and we need to think about all the success criteria from all the groups

Lisa: Do you want us to give a success criteria and a recommendation of a guideline?

Kathy: In Mobile, we have a document with all the success criteria grouped by new guidelines
... we all have our own ideas, but we have cross-work that we need to do.

Joshue: For the page we have, we only are recording the success criteria, and how we organize it, will come later.

AWK: [shows the template and the entry for the Guideline]

Kathy: But you need a diagram of what new success criteria falls under what Guidelines, especially new guidelines

Support Personalization

Issue 6 Support Personalization

<AWK_> https://github.com/w3c/wcag21/issues/6

<Lisa_Seeman> https://rawgit.com/w3c/coga/master/extension/support-personalization.html

AWK: This is a much longer proposal

<Joshue108_> So for future referene for each new proposed SC - if it may result in a new Guideline etc add it under the heading in the SC 'What Principle and Guideline the SC falls within.'

Lisa: I put it all together, and some of it may be moved into the glossary, but that's a formatting issue
... what are the semantics needed
... what are the personization settings needed
... there is an exception that the information doesn't need to be exposed when there is not a standardized way of doing it.

Support personalization: Contextual information and author settable properties of regions and elements are programatically determinable so that personalization is avalible.

Where the number of steps in a process can be reduced, the user can control the trade off between function and simplification.

Exception: Information does not need to be exposed when there is not a standardized way of exposing it in the technology or the platform.

[Contextual information includes: context of elements; concept and role; relevance and information for simplification; position in a process.

Author settable properties includes: type of distraction, type of help, type of transaction and type of reminder, instructions and status of an element.] - note this could be in the main text or in the definition

Michael: I like most of what it does, but I have some structure issues
... I don't think you should rely on semantics
... remove the exception, and have the rewording I suggest.
... in a future version of WCAG, we could go further.
... "can be personalized" is the rewording I suggest.

James: The exception would be very difficult to use. The example is a page that meets the success criteria, but I modify the page and now it doesn't meet WCAG.

<Joshue108_> NOTE: I updated the SC template - with a section about mappings to work in other TFs https://github.com/w3c/wcag21/issues/1

James: I am also concerned how broad it is, you can't personalize everything -- there is no way to be able to support customers.

Support personalization: Contextual information and author settable properties of regions and elements can be personalized

John: Success criteria needs to be @@

Kathy: On mobile, there is specific assistive technology, we limit it to the assistive technology on the platform, and supporting the assistive tech on the platform with non-interference

<Joshue108_> +1 to MATF and COGA working together on personalisation.

Lisa: The phrasing that Jeanne put in IRC doesn't make sense.

AWK: We will work on the details of that.

Lisa: Looking at an older version of the SC, because that is closer to what Mobile TF is doing.

Kathy: There are very specific settings --- you can't support personalization of every app.

Joshue: Then it is the never ending -- like the access keys

Kathy: For example, JAWS wouldn't apply, because it isn't platform based.

<Zakim> AWK, you wanted to ask Michael about prog set vs personalization

Kathy: there is SO much personalization in the new iOS 10

<Joshue108_> +1 to using an authoritative channel for managing personalisation thru, else its potentially a tower of author preference babel.

AWK: When you are suggesting removing programmatically determinable, it seems like the opposite of what we usually do in WCAG.
... I think what we need is the crispness of, for example, headings. Obviously, it is more than headings.
... we have specific callouts for specific semantics, we have to present broader that will address different authoring needs.
... we don't want people to just say that increase the fontsize then meets the personalization SC.

John: Even if a program doesn't exist, you have a hook for it.

James: I think this might go more in @#@

<Lisa_Seeman> https://w3c.github.io/personalization-semantics/

Lisa: It's not covered today, we need wording for how it will work today and also how it will work later
... If people go out of that, there are control testing of user settings, we think 5 is most we can ask for, if people want to do more, then it is on them
... we would have to come out with definitive guidelines on the test suite.

James: iOS exposes wonderful things, but a ton of them aren't available in a web application

Kathy: Agreed, and there are specific techniques

James: It's a moving target and constantly changing

Kathy: We can't limit ourselves because it isn't available today. We have to push people to be able to do more personalization
... there is a tremendous research on personalization
... I agree with James on what can be done on the web, but we can't say that we aren't thinking about it.

Lisa: it would be great to get Apple and Google to standardize

<Zakim> Joshue108_, you wanted to say what about not AT users with COGA requirements. Is this SC too focussed on programmatic determination. Sounds like a Silver project.

Joshue: We have to put this in Silver. Semantics are all about assistive technologies, and it mean the user agents have meet us half way.

jeanne: +1

Lisa: We need to define semantics and safe standarized techniques

Joshue: What are unsafe standardized techniques?

Lisa: usual example is those that are related to marketing and influencing people to increase profits.

AWK: There are lots of semantics, which ones would I use? I don't know what I would tell a developer what to do to meet it.

Joshue: A lot of it is predicated on name, role state

Kathy: But in mobile, text size means to support to the platform settings. That's not name role state

Joshue: We could &&

Kathy: Mobile proposed an SC under 4.1 that extends 4.1.2

AWK: We can't put something into a guideline that doesn't have specific things that the author can do.

Lisa: The original wording would meet our needs.

AWK: The challenge is that there are a number of things that need to be merged in all the Task Forces
... "here are a handful of things you could do"

Lisa: But that sounds more like Techniques

Joshue: Personalization is not just COGA. WE need to take it outside COGA

Kathy: I think this needs to wait until December, when we can see it as a whole.
... we can't come to an agreement today. Mobile addresses A, COGA addresses B, Low Vision addresses C.
... we can't intermix it now.

Joshue: Personalization has to be addressed as a group. If you say personalization is available, look at Techniques, done.

Lisa: Our version was completely dependent on Techniques
... the advice we were given was to get broader, which drove us crazy.

AWK: What does the universe of Personalization look like?

<Joshue108_> +1 to the support personalisation Guideline.

John: A lot of Personaization is under the Robust principle. Maybe we have a 4.2 with Personalization with a success criteria with different threads. When developers come to us and say, we getwhat you want, but how do we do that?
... get everything out there and then look at it.

<Joshue108_> If we tried to do this in 2.1 this could start a dialog and set the groundwork for Silver.

John: a new Guideline would make it easier to bring them together.

Kathy: Then you could break the SC into more manageable chunks.

Lisa: Submit the success criteria as they are, then in December, WCAG WG looks at the whole universe and puts it together.

<David_MacDonald__> +q_

Lisa: So we don't have to go crzy about the wording, because WCAG will rip it up anyway.

Kathy: Mobile TF is focusing on the research, the problems and the benefits, because we know that WCAG will change the wording

Joshue: This is very exciting.

Kathy: We will need a task force to merge the Task Forces

AWK: It will be a focused study

David: What can we do is what John said about making a new Guideline
... create a bucket, and we can start putting things in it.

Joshue: Personalization will capture people's attention

Lisa: the personalization space needs to pull in other groups.

<JF> https://www.w3.org/WAI/ARIA/wiki/Meetings/TPAC_2016#13:30-14:30_Cognitive_Accessibility_Task_Force_Interlock

<David_MacDonald__> New Guideline: Provide a means to allow personalization of the presentation of the content

RESOLUTION: Needs to be considered at the same time as MATF and LVTF personalization items, possibly a new GL group.

<AWK> +AWK

<Rachael> scribenick: Rachael

<Kathy> https://gist.github.com/patrickhlauke/96110b10547770021e58f5098dd31087

<Kathy> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/WCAG_2.1_Success_Criteria_Submission_Requirements

AWK: Welcome back. We will be talking about mobile. We thought we'd been talking about individual success criteria but after this morning we want to take a slightly different tack. We will start with a high level view from the 10,000 foot view. Big picture first, then zoom into the different pieces some time after that.

Kathy: First thing we did was to look at mobile and determine what's different from desktop. What has changed.

<Kathy> https://www.w3.org/TR/mobile-accessibility-mapping/

Kathy: People in general face issues on mobile.
... This document shows how WCAG 2.0 apply to mobile.
... a number of techniques will go into current success criteria. We will not discuss this today but we have it documented.
... What is different: Smaller screens, different ways of interaction. What came out was that things that are different are not just for mobile. We have touch screens on desktops, etc. So the things we talk about are not exclusive to mobile but are required for mobile.
... 3 different areas for success criteria: touch and pointer, personalization and interaction that is inherint to mobile (portrait to landscape interaction)
... I want to give a high level view of all the different success criteria for touch and pointer specifically. One of the challenges we've had, is keeping the existing criteria for keyboard interactions and work touch and pointer in. They are intertwined. The success criteria can't be examined alone.

<Kathy> https://gist.github.com/patrickhlauke/96110b10547770021e58f5098dd31087

What we are discussing is in the link.

Patrick: Wanted to look holistically at input. Good opportunity to patch in different types of inputs not sufficiently covered in WCAG.
... Current bias is towards keyboard accessibility. There is a base assumption that developers design to work with mouse. WCAG adds keyboard. Newer technologies on devices allow a fully accessible application without a keyboard or mouse.
... Sometimes users have a bluetooth keyboard but that is not always the case.
... Some patterns in techniques fail on devices. The documents attempts to go through all input devices. Keyboard is fully covered. Assuming that it can't be changed, I've added about 5 more areas.

AWK: What pushback did you get that we shouldn't change the existing criteria?

Patrick: General pushback on not changing existing items.

AWK: It is not clear for 2.1 that we are not open to adding new SC.

Kathy: Right now we've created SC to be added. When we first started with adjusting Keyboard criteria, the thought after a bit was that we were changing too much. I think its important to look at each of the success criteria.

Josh: Question: Keyboard is a type of pointer. Can we generalize them under pointer?

Patrick: There is something about pointers being about to target a particular XY value on the screen.
... at a very high level, everything boils down to be input agnostic.
... generalizing everything to be input agnostic, maybe a step too far.

James: When keyboard was written, keyboard was the primary way of interacting with information. Do we risk in 5 years that pointers are not the primary way of interacting?

Patrick: I did add a SC that will allow abstraction to future devices.

AWK: One solution will be to ensure WCAG can be refreshed more often than every 8 years.

Kathy: We called out touch specifically but added a definition that expands touch so that it applies to all pointers.
... if touch doesn't apply, then like video, it is skipped.

Jeanne: We can look at keyboard as sequential navigation and touch as direct navigation

Patrick: Overview. We start with keyboard then suggest a section on Pointer accessibility. This is currently implicit in WCAG 2.0. This should be an automatic pass becuase this is how most developers develop but its included for completed. The argument for inlcuding this is that somethigns in the future may not be designed for mouse interaction.

[brief off topic discussion of target size]

Patrick: Next section covers gestures. If something is built into the OS that handles gestures then you can exclude some of these. We will need an exclusion based on this. Users need a way to back out of gesturebased actions.
... most features already implemented something like this where it only activates on the removal of the pointer (up gesture).
... Then we discuss variations based on use of AT.
... AT usually remaps keyboard inputs for example. Making sure that functions still work on those scenarios. The next about touch with AT, is there becuase the AT will intercept the gestures and interpreted as a command to the AT. So the gestures may not be passed down to the application level.
... I consider pass throughs in AT to be a workaround

Josh: Its also a poweruser tool

Patrick: The next, input agnostic, is about whether you only focus on input agnostic events (onclick, onblur, etc) but its really about making sure that your content works regardless of input mechanism.

<Kathy> This page has links to the success criteria that has been written by the taskforce: https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/WCAG_2.1_Success_Criteria_Submission_Requirements

Patrick: The turn off shortcuts is about certain situations where the single key shortcut keys built into the application can cause problems for AT users. Users need the ability to turn them off. Multi-key shortcuts can still cause problems.

Kathy: the link goes into more detail.

Patrick: The no focus trap is the best candidate for merging with the existing focus keyboard trap SC. It tries to dover the various scenarios.
... 2.7 is another new block on inputs. Looking at some of the more advanced items beyond a keyboard, touch, and mouse. Accelerometers for example. Its about making sure those are accessible and covered in WCAG as well.
... many of the styluses allow not just XY detection coordination but also pressure sensitive (ex: 3D touch) and on advanced styles include tilt. Not yet implemented yet is twist around the zed axis on the pen. This is a catch all.
... usually drawing applications but in the future applications may do one thing with light pressure and another with alot of pressure.
... again it will cross over with what the OS allows. It may be a shortcut (example: IoS will give you a list of functions when the user presses hard and as long as that list is available another way, that's fine).
... The next item is covering device sensors. This is only sensors used actively by useres. Not a GPS tracking steps but shake to undo.
... There are situations for all users that these may not be avaialble. It may not be in the device or the device may be permanently mounted.
... there are a few other SC that we are suggesting that are not input related.

<Zakim> Joshue, you wanted to ask my silly question, will people looking at this know that pointer events relate to mobile devices as opposed to touch? and to ask about the grouping of

<AWK_> +Laura_Carlson

Kathy: We included these in the links but I think we should focus on the link and pointer items due to time constraints.

Joshue: Great job. Where else is this referenced and used?
... what terms should be used?

Patrick: We do have a glossary.

Kathy: That is why we have definitions and references to other specs.

Patrick: We initially looked at doing something more comprehensive If the user has a touch, mouse, etc then ... The problem is this gets very lengthy and its not future proof.
... the term Pointer will have to be marketed. It should become more accepted and generalized.

Kathy: The understanding document also tries to cover this.

Joshue: I see some are keyboard with AT, some are touch with AT, and some are pointer. Is the thinking that they will continue to be grouped that way? The grouping is necessary but what is the thinking about it going forward? May be confusing for developers.

Kathy: We had them grouped togehter to start with but then we broke them out based on feedback.
... we are looking to the WCAG working group to make that decision.
... We think its best to lay out the various options and then let the working group .

<Zakim> jamesn, you wanted to ask about 2.6.1

Patrick: Criteria may be grouped but there is a danger of writing an SC at so high level that it is almost meaningless. The differences would have to be dealt with in the techniques but then we have lots of techniques are based on the front end. The answer to what do you need to look at is that you need to look at all them. Input device use is all blury.
... Unless you are buildign something like an ATM where you know the app is only going to run on that AT, you have to assume a large range of items. Short answer, look at all of them.

James: WRT 2.6.2, this may be a AAA. If users have to use a passthrough and its well documented its not a bad experience.

<Zakim> alastairc, you wanted to ask about whether they all fit under principle 2

James: WRT 2.6.1, there needs to be a way to turn them off or only fire on certain points of the web page.

Allaister: Are they all under 2?

Kathy: We have one under 4 Robust.

Alastair: Its interesting. Low vision ended up falling mostly under 1.

Kathy: The taskforce focused on input because that was where we felt we could have the most impact. There were other areas we could have focused on but not with the time constraint.

David: There are different levels of consensus and vetting on these. We have good consensus on 2.5.4, on 2.6.2, and 2.5.2

Joshue: Fantastic work.

Kathy: It took a really long time to get to this point.

David: hundreds of hours.

<Joshue108> https://github.com/w3c/wcag21/issues

Patrick: We have started putting them in a template. Once we are all happy with them, they we will be able to push it very quickly.

Joshue: I trust what you are doing very much. We rely on your expertise becuase I am not an expert.

Judy: Question to the taskforce because I know how long they've been working to respond to previous rounds of feedback. Do you feel that you are getting clear enough feedback to do the next stage? Do you need anything from the working group to move forward? Any concerns?

Kathy: One of the challenges we have is the working group looking at items in isolation which is why I pushed to focus today's conversation on the criteria as a group. We are still working through this and will be till the Dec deadline. Is there any big red flags from the working group from a high level? If something is not going to work we should know now.
... this is the core of what we will be bringing in December.

Andrew: I am interested in what the other two are.

Judy: What is the plan for additional sync points between now and December?

Joshue: We have regular inter-task force calls to coordinate touch points.

Andrew: There are challenges there too becuase its easy to dive down into the weeds.

Kathy: I think its important to work through this based on feedback.
... the other two that we have is on orientation, moving between landscape and portrait and the other is noninterferance with AT which we discussed this morning. It falls under Robust.

Andrew: Do you feel these are readily achievable today?

Kathy: Yes, we have test criteria. We are not waiting on something to be implemented.

Andrew: Its not waiting for new technology to be implemented but rather ensuring we are speaking in a technology independent way.

<Joshue108> R: I heard it today in the group..

<Joshue108> R: We rely on these sets of criteria with AT..

<Joshue108> R: The dPub group is documenting metadata, do we have anything like that?

<Joshue108> RM: It could be user info about quick keys etc.

Kathy: The challenge is that technology is changing. We need to figure out what is good for today as well as down the road. Next year we will be talking about some other way

Rachael: Do we have a standard that includes documenting best ways through, assumptions of setup, etc.

Judy: The authoring tools has something along these lines. It should be clear, it should be highly discoverable.

Andrew: Is there anything else that would be valuable for mobile? We break in 15.

Kathy: We do have a few success criteria we can dive into.
... since James has feedback we could discuss the touch target size.

<Kathy> https://github.com/w3c/Mobile-A11y-Extension/blob/gh-pages/SCs/m2.md

This has been modified.

Kathy: course and fine were taken from another spec.
... we do have an extensive evidence section based on industry recommendations and academic studies.
... One thing to note is that there are differences in size recommendations between points, mm, px, etc. dp is the same as 1 CSS pixels. We didn't feel that using mm on a screen was useful [general agreement] because it varies by screen. We are not pulling this out of thin air.
... we ended up taking 48x48 px for course and 24x24 px for fine mostly based on Google recommendation. Some alternatives do recommend even bigger. We do recommend in the understanding that common actions use a larger size.

Patrick: All those guides refer to the course. There are no guides that refer to the smaller pointer size for mouse users so we used half the size.

James: I think we need to have an approach that dictates an overall size without specifying the height or width.

Patrick: If we can find a way to explain it that avoids the absurd (2 px high but 600 px long) then that makes sense.

James: This should also be excluded when touch is the secondary way of interacting.

Patrick: Its about the writing to ensure there is an alternative.

Andrew: It also ties to feedback and the selection (release).
... My question: what is a target?

Patrick: It is the activatable zone where something happens.

Andrew: So you can place them right next to each other?

Kathy: They can be overlapping as long as the touchable region is the correct size.

Andrew: For someone with tremors, I was wondering if it was an issue.

Kathy: We've added and removed the padding requirement several times.

<Joshue108> ack meack me

Shadi: Links close together is not just a problem for folks with tremors. There should be some mechanism add padding. The address book is a good example because I call the wrong person.

Joshue: The link halo is an example of that helping.

Judy: It may be helpful to look at very specific types of user requirements. Tremors, spasticity, granularity of hand movemements for example.

<laura> Thanks!

<alastairc> scribe alastairc

<alastairc> scribe: alastairc

AWK: Intro to Jim, the facilitator of the Low Vision TF. Working on SC proposals, please give us an overview.

Jim: High level - we have 18 SCs that we are working on, 5 that are now in Github for review.
... Most of the 18 have to do with customisation, and are often quite granular, they might be combined later.
... 2 are covering contrast issues, and another on overlapping items (due to zoom/font-size changes).
... A couple more in the works that aren't ready to discuss yet. There is a requirements document for user-needs, but mostly it is for the user to have control of their environment.

AWK: There was a discussion with COGA about personalisation, there might be a section / guideline for supporting customisation, so some LVTF ones might fit in there.

<allanj> https://github.com/w3c/wcag21/issues/10

Contrast Minimum, github issue 10.

"The visual presentation of interactive images, form field borders, and focus indicators have a contrast ratio of at least 4.5:1."

Jim: Because some of the new designs with minimalist designs are a problematic, where imagery / icons are difficult to see.

<jamesn> exactly what I was going to ask

Kathly: Why 4.5 to 1, not 3 to 1?

Jim: Quite a few of these are 1px wide, where borders are very thin, or form controls with just an underline.

Kathy: For interactive images, could be any size. This seems like more than what we should be requiring.

AWK: Can we set aside the ratio, focus on the elements that it applies to.

<JF> preseent+ JF

Jim: If we polled the group, it would be form controls are the most important, then focus indicator. However, there are issues with interactive images, e.g. buttons with low contrast. If the contrast of the word isn't there, or the picture of the icon is too low contrast we can't tell what it is, regardless of the size.

MichaelC: For threshold, we should harmonise with rest of WCAG. For interactive images, not sure what that means? Might need a definition. Is it primarily the border?

Jim: Not sure, will take that back to the group.

AWK: I remember that it could be a button that uses an image, e.g. with a printer in the middle.

MichaelC: Because images of text is also in there, that adds a meaning for the text pixels vs background. Cramming the others in also means it has to be defined better.

David: Same concerns about what interactive images means, does it apply to things like graphs? Form fields, do you mean the inputs?

Jim: Yes, some lack borders.

David: How about if the background colour of the button is enough, but doesn't have a border?

Jim: We can thrash it out, just need to know the pain points that the group have.

Kathy: In this SC, why is it calling out specific interactive components, why not generalise? These might be common now, but there are other coming along such as ARIA-tabs.
... Focus indicators, the browser is responsible for that, and they are not all currently sufficient, so we are saying that we can no longer rely on that. Do we want to take away that customisation? In our research, we've found the difference between focus and other states is tricky.

Jim: The browser does it, but sites can turn it off, so we want it to be on and easy to see.

Kathy: We're talking about custom focus indicators, rather than the default ones. If you customise it, and provide something specific, then these apply. However, I don't think it applies if you rely on the default one.
... This is saying that sites have to over-ride the default, we should only do that explicitly and be sure that is what we mean.

<Zakim> MichaelC, you wanted to wonder if interactive image is complex enough to move to a potential other SC, and keep the other additions which seem more straightforward and to or to

Alastairc: Suggest only if you override the default.

MichealC: If we feel that it is important enough for accessibility, then we could make it a guideline. With WCAG 2.0 we published some things that browsers weren't doing then, but we thought they should.
... It seems that the interactive images part of that SC is the complex one, perhaps we should move it out. The other bits (forms & focus) seem to be more straightforward. We could move those ahead, and deal with the interactive images bit separately.

<laura> Separate SC: Informational Graphic Contrast (Minimum)

<laura> https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Informational_Graphic_Contrast_(Minimum)

AWK: One of the questions was about form fields. Taking the github page example, many of those form controls do not have much contrast. Big concern about requiring all form controls have to have borders.
... But, trying to balance what designers want with what users want.

<mhakkinen> +q

Kathy: Also have to consider the colours available, it can get to the point where you can't do it.

Jim: Some of the buttons have 2:1 ratio, some of the text isn't that contrasting. This is what drives people nuts, you can't see the buttons/controls. It seems to get dimmer and dimmer as we go on.

<Joshue108> AC: I was worried about the requiring borders aspect.

<Joshue108> AC: Todays controls are custom.

<Joshue108> AC: Some part of the control will need good contrast but not just the border.

Mark: Kathy mentioned difference between selected states and focus. We hear that, where younger test-takers struggle with mixing mouse / keyboard selectors, and thinking the focus indicator is the same as selection.

Kathy: Adding contrast could add more confusion, we need to think about that form a design perspective. People with low vision do need the contrast, but we have to balance that with other user's need, could run into unintended consequences.

Racheal: Also issues with cognitive load, if everything is contrasting you can't prioritise the interface enough.

<Zakim> MichaelC, you wanted to yammer about persoalization

Rachael: Have issues with placeholder text is also an issue, needing contrast but not wanting to make it seemed filled in.

MichaelC: Just want to get on the radar, the concern about impairing design, the solution tends towards personalisation. How much is: suck it up and deal with it, and how much is pushed into personlisation.

AWK: The LVTF recognises that what would be best is for authors to use any type of form field, and the user had an easy way to change to what makes sense for them.
... That might exceed what we can do in 2.1, but we will need it at some stage (silver?). What can we do now is difficult.

<Joshue108> AC: Can I suggest, we can threathen to make these the requirements and get the designers to adopt the requirements.?

<Joshue108> ak me

Josh: Helps to follow an established convention, they can expect some behaviour from the appearance of form controls.

<allanj> Informational Graphic Contrast (Minimum)

<allanj> https://github.com/w3c/wcag21/issues/9

Jim: Number 9, Informational graphics. We've discussed it a lot, e.g. having a pie chart how do you get 4.5:1 for 5 colours? Perhaps using a pattern, or put a key on the thing. We came up with those but thought we'd leave it in anyway.
... Issues with colour blindness where you can't tell one piece from another.

MichaelC: Clarification, is this proposing a different thing to the same SC?

<Joshue108> wonders if it should be called Informational charts and graphics Contrast (Minimum)

Jim: The previous one was more interactive, this is static image that isn't interactive, but both are modifications to 1.4.3.

<shawn> [ LVTF not sure about separate vs. grouped points and welcomes WCAG WG guidance on that in general ]

AWK: Not modifying 1.4.3, could be additional.

Kathy: Talking about many different things, again calling out 4.5:1, but then could be 3.5:1 for slices of a pie chart. There are other ways to make things distinguishable, and don't want to stifle creativity around how people can achieve that.

<allanj> agree

Kathy: E.g. having different slices of the pie become interactive. There are many ways to do it, and there was a lot of push back against 4.5:1, because it conveyed specific information. So we came up with other ways of doing it, which was visually apparent (tested with real users with LV).
... If we have something that states a minimum contrast, we need to add some exceptions, and there are other ways to achieve that from a usability point of view.

Jim: Good feedback, we're still working on it.

Rachael: I've run into issues where visual distinction applies, this seems like a technique to achieve something rather than the requirement itself.

David: If we start limiting colours in the graphs, that will be a nightmare from a design perspective, I don't see how we can limit the colours without impacting other people. What is it contrasting against? The background? Each other? That needs some work.

<Rachael> Contrast is one technique to clearly distinguish borders in graphics and maps.

AWK: In the task force, this is a slippery slope item. E.g. with an icon conveying information in a page (with alt text), it is functioning like text to convey the content, but without good contrast. E.g. a 'new' icon next to a movie in a listing. How to we make sure that sort of icon is accessible with contrast requirements, without impacting complex implementations like heat maps.

<laura> Example: Status icons on an application's dashboard.

AWK: If you are a Christmas store with red & green icons...

Kathy: It is largely about single colour icons conveying information. (Not a problem if also has text.)

<laura> https://github.com/w3c/wcag21/issues/5

<laura> https://github.com/w3c/wcag21/issues/8

<allanj> Seeing All Interface Elements (LV)

<allanj> https://github.com/w3c/wcag21/issues/8

Jim: Seeing all interface elements. "Users can see and interact with all content and user interface controls presented visually.", related to 1.4.8
... See the images in the issue, it's where increasing text size creates overlap between elements.

<Joshue108> AC: There is a requirement for increasing the size of text without increasing other elements.

<Joshue108> AC: What is the problem with also zooming images?

<Joshue108> JF: Horizontal scroll.

<Joshue108> RM: Is that a failure?

<Joshue108> JA: Dont know if it is.

<Joshue108> AWK: Its not when things go off a page?

<Joshue108> AC: With a RWD that shouldn't happen.

<Joshue108> AC: Its only the text only version of this thats the problem.

<david-macdonald> https://www.w3.org/WAI/GL/wiki/Possible_wording_from_Jason/David_for_LVTF_re:_zoom_without_horizontal_scroll

MichaelC: The proposed wording doesn't seem to achieve what I think it aims to do. Some aspects are supposed to be true at all times, but this only upto 200%? Gets confused when expanding a guideline. 1.4.8 (triple A).

JamesN: Doesn't 1.4.4 cover this, as overlapping text is an issue then. Tooltips are an issue, but then they don't work in other cases either.

Rachael: If this goes forward, I'd ask for technical constraints like how much zoom, what size etc.

David: We have worked on an expansion to 1.4.4, not specifically on the overlapping issue but it is in the same space.

<laura> Size (all content): https://github.com/w3c/wcag21/issues/12

<allanj> Size (all content) (LV)

<allanj> https://github.com/w3c/wcag21/issues/12

Jim: Size of all content.

Kathy: This is required up to 200%

<laura> Look at the test:

<laura> 1. Display content in a user agent.

<laura> 2. Increase zoom to the maximum.

<laura> 3. Decrease zoom to the minimum.

<laura> 4. Check whether all content scales and is perceivable with no loss of content or functionality (e.g. boxes do not overlap, controls are not obscured or separated from their labels, etc.).

Jim: Wanted to elevate the importance, and add a bullet point.

<Zakim> MichaelC, you wanted to worry about intersection with layout wrt small viewport issues etc.

MichaelC: Wonder if we can realistically that say you can resize everything, whilst not clipping.

<Joshue108> AC: I'd urge everyone to look at the work David and I did, and expansion of 1.4.4

<Zakim> Joshue, you wanted to say this sounds like truly responsive design.

<allanj> AC to you have a link to the expansion of 1.4.4

Josh: Not sure of the difference between that and some of the others.
... There are a lot of variables, spacial relationships can be temporary.

JF: It says that we're adding a new bullet to something that is about blocks of text (only). Also, going from triple-A to A would get serious pushback.

<Joshue108> AC: I'd say the change to 1.4.4 would change that too.

<Joshue108> JF: Maybe it needs to be a new guideline or a new SC.

Kathy: Researching for the mobile work, something that came out was that there are differences in content. Reading on a smaller screen (paragraphs) wanted to increase text size, but not the menus. Magnify when needed. Be careful that we write or change, there are differences in the content.
... Users with low vision have done videos on youtube.

<Joshue108> AC: Just to add, when David and I worked on the Zooming SC, it is a noticable hole how this is handled.

<Joshue108> AC: You cant in a page do the same things on a web page and a mobile device.

<Joshue108> KW: Depends on how media queries are set up.

<laura> Text Size (LV) #11 https://github.com/w3c/wcag21/issues/11

Jim: We'll continue working on it, and refine it.

<mhakkinen> +q

Jim: It got very complex when we tried to modify SCs, as they build on each other.

MichaelC: Don't want to fret about what it fits under, just get them out there, and we'll sort (and filter) them later.
... Could end up with some re-structuring, where similar ones get combined.

Mark: The relationship to colour contrast, we have designers get prickly when picking thin typefaces. When you visually look at it, there are not many pixels with sufficient colour contrast.

JamesN: The standard says you can test it without anti-aliasing on, so these would pass.

MichaelC: We've run into issues before where issues with the guidelines are actually ok, but some testing practices weren't quite right. Might need to provide better guidance on testing.

Kathy: When you have a thin font, 4.5:1 may not be sufficient, LVTF might want to look at thin fonts?

MichaelC: Imagining a function that detects the widths...

Mark: It would help if there were some further guidance on this in 2.1 that helps describe it.

JamesN: If someone creates a new user-agent with 1000000% zoom, I then have to test for that. Think we need a maximum so it is testable.

AWK: From some of the discussions, there is interest in zooming up to 1,600% which none support.

MichaelC: 200% was for authors, making it possible.

JamesN: Is responsive approach what LV people want?

<allanj> Thank you all. very helpful

AlastairC: In general yes, have spoken to Wayne and seen testing as well.

<laura> rsagent, make minutes

- DRAFT -

Web Content Accessibility Guidelines Working Group Teleconference

19 Sep 2016

Attendees

Contents

Introductions

Review COGA SC Proposals

"Small" change to 3.1

Support Personalization

Issue 6 Support Personalization

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output