<lisa> i am on the webex

<AWK> +AWK

<Glenda> scribe: Glenda

Introductions and logistics about microphone/speaker phone

<lisa> much worce

<lisa> it was clear a few minuets ago but now I can not hear

<laura> Can hear AWK very, very faintly.

<lisa> NO

<lisa> cant hear

<laura> yes

<lisa> a bit

Timeline review/path to CR

<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_timeline

<Glenda_> AWK: Good progress. Moving Final Public Working Draft to Jan 9, 2018.

<Glenda_> AWK: Some pressure to have final rec before June 2018 due to EU needs. At this TPAC we need to workthru and address contents so we can meet the Jan 9, 2018 final public working draft deadline

AWK: Starting now with implementation criteria.

1) At least 5 conforming Web sites [1] are available, of which:

At least four conform at level AA,

At least one conforms at level AAA;

Kathy: what is the definition of web site?

AWK: 5 or more pages.

<lisa> cant hear

jnurthen: what about 1 page web application

<lisa> i dont understand 2

<AWK> https://www.w3.org/TR/2008/CR-WCAG20-20080430/#statusnote1

2) At least two implementations [2] exist for each success criterion added in WCAG 2.1 (Success Criteria from WCAG 2.0 do not need new implementations);

skipping 3 for a moment

4) All sufficient techniques listed in Understanding WCAG 2.1 at the end of the Candidate Recommendation period contain test procedures;

5) The Working Group has responded formally to all issues raised against this document related to any implementation efforts during the Candidate Recommendation period

jumping back to #3

3) Accessibility support documentation [3] that provides evidence of successful support for SC added to WCAG 2.1 with platform, user agent, or assistive technology dependencies is available for at least two technologies with at least four platforms (operating system/user agent/assistive technology combinations);

<lisa> what is a technology?

This version addresses Brook’s concern that we provide evidence of successful support

<lisa> in this context

<Joshue108> much better Lisa

Lisa: requesting clarification on what you mean by technologies and what you mean by platform?

AWK: On platform - OS, UserAgent, AT combinations. MacOS/Safari,VO, Windows/Chrome/NVDA, Windows/Edge/Narrator, Windows/IE/JAWs would be an example of 4

<Zakim> laura, you wanted to ask about SCs that are already scoped to less than 2 technoogies. Such as 1.3.5 Contextual Information and Adapting text

Lisa: what is technology?

AWK: In WCAG 2.0 times…technology was HTML, CSS…

<AWK> https://www.w3.org/WAI/GL/WCAG20/implementation-report/

<AWK> https://www.w3.org/WAI/GL/WCAG20/implementation-report/accessibility_support

<Joshue108> Is PDF a markup language?

<lisa> no

<lisa> pdf is not a mark up language

AWK: note that we need to address any technology that is not a markup language.

<bruce_bailey> Here is the URL for the email AKW just sent out with Current version of Implementation criteria for discussion

<lisa> do we need to invent a new technology

Laura, can you type your question (for the minutes)

<KimD> Is this the reference? "To demonstrate that accessibility support for technologies can be determined and documented, data on the accessibility support of four Web technologies was gathered. All were evaluated with multiple platforms (operating system/user agent/assistive technology combinations). The Web technologies tested and documented included both W3C and non-W3C technologies (HTML, CSS, PDF and Silverlight). "

<bruce_bailey> http://lists.w3.org/Archives/Public/w3c-wai-gl/2017OctDec/0312.html

<Joshue108> couldnt hear Alex - so thanks.

<laura> Need clarification: If we must have 2 technologies, if the SC is already scoped to less than 2 technologies. Such as Contextual Information and Adapting Text.

Alex: For mobile, what if we have a proposed SC where nether iOS or Android have a way to meet it? We need to make sure every criteria both in WCAG 2.0 and WCAG 2.1 can be met on iOS and Android.

<Zakim> Makoto, you wanted to ask if Japanese screen reader can be one of 4 platforms or not.

Makoto: What abou the Japanese only screen reader?

AWK: We need to set a sufficient baseline that support is achievalbe more broadly.

<Joshue108> sounds ok

<lisa> I would love to learn!

Jasonjgw: CR Exit Requirements needs to have consideration for Mobile (related to Alex’s question).

<laura> didn’t hear jason

Katie: point back to what Kim said, “Is this the reference? "To demonstrate that accessibility support for technologies can be determined and documented, data on the accessibility support of four Web technologies was gathered. All were evaluated with multiple platforms (operating system/user agent/assistive technology combinations). The Web technologies tested and documented included both W3C and non-W3C technologies (HTML, CSS, PDF and Silverlight). "

<Zakim> jasonjgw, you wanted to discuss accessibility support documentation

<jon_avila> At the time I think we had xhtml as a technology.

Lisa: Can add a footnote about showing wide support. Some enablements are better than other enablements. We want to make sure that the intent is to show robust support.

<Joshue108> -q

<Zakim> AWK__, you wanted to say that we are trying to establish guidelines that are technology-independent

AWK: We are trying to establish technology independent criteria.
... we need to be careful about defining advice that can only be used in one specific technology

<AWK__> reagent, set logs world

<Zakim> Joshue, you wanted to say I don't think we are beholden to popularity

Joshue: +1 to what AWK was saying. This notion of popularity. I don’t know what degree we are held to. We do strive for broad support.

<lisa> i sugested a foot note about scope

AWK: Implementation Exit Criteria - what suggestions do some other have

<Brooks> Documentation [3] that provides evidence of accessibility support for and immediate user benefit derived from SC added to WCAG 2.1

<lisa> if some technologies are out of scope for a success cryteria then one technology may be enough

<chaals> [+1 to Brooks that we should demonstrate the improvement...]

Brooks: we want to put forth SC that yield an improvement to the user experience for people with disabilities. Real change for real people.

<laura> +1 to Brooks

AWK: what is sufficient quantities of evidence. I believe that Brook’s proposal and the current proposal are trying to say the same thing.

Lisa: suggests “if some technologies are out of scope for a success cryteria then one technology may be enough”

<gowerm> -1

<Zakim> jasonjgw, you wanted to DISCUSS USER BENEFITS.

<laura> +1 to Lisa

<lisa> mike, do you have another idea

<lisa> if the scope is for markup laungages, what two technologies do you suggest we use?

<AWK__> perhaps EPUB?

<gowerm> if something is only met by one technology, it is not technology agnostic.

<lisa> epub is html

<lisa> pdf automaticly conforms

<Joshue108> I think Lisa has a point

<Ryladog> epub is a package of technologies including HTML

Jason: the point of WCAG is to benefit users. I want to resist the existance of imperical evidence as an exit requirement due to unrealistic time/resources. We are crafting WCAG 2.1 with direct user benefits as the primary goal.

<Zakim> JF, you wanted to ask how we measure "immediate user benefit"?

<lisa> the pages, that you would add it to is html

<Zakim> Joshue, you wanted to say Lisa brings up and interesting point, what about niche requirements?

JF: how do we measure an “immediate benefit”…but that is subjective. I believe in the content, but I’m concerned about this language.

<laura> Maybe remove the word ‘immediate” on Brooks proposal.

Joshue: if a new SC is out of scope (not relevant to particular platforms)…has a more narrow scope, it may not be able to satisfy our currently proposed exit requirements?

<lisa> we are requiring multiple platforms

AWK: asked Michael Cooper to look up how we handled this in WCAG 2.0.

<Zakim> chaals, you wanted to say research is hard, but important to allow grounded discussion...

Katie: Agree with Jason. These SC were created the the TF’s because they will help users. I believe the intent is valuable. But that the gathering of this evidence is not needed.

Chaals: wants so support Brooks. You should demonstrate how it helps users.
... well before you try to run it through CR, you have demonstrations of how it helps.
... also make sure it doesn’t break something for someone else. It is valuable to explain the benefit to users and we have had other people check it across other use case scenarios. I don’t think it is a huge burden. Just put it online and let people kick it around. Very reasonable bar.

<vivienne> completely agree with Chaals

<Zakim> AWK__, you wanted to say that we do have requirements that SC are helping end users, the CR criteria are just to provide some quantification

<Joshue108> thanks Chaals

<Jan> +1 Chaals' comments

<jon_avila> Implementation summary from WCAG 2.0 https://www.w3.org/WAI/GL/WCAG20/implementation-report/characteristics

AWK: We are substantially doing that. The CR criteria are the data for exit. I’m wary of having something close to user testing…if we did, we will need to figure out how we would resolve every comment, and what percentage of success.

<Joshue108> thanks jon

Kathy: I agree in principle with meeting ends user needs. The work we’ve done in the TFs came directly from user needs.

<chaals> [this should not be a huge extension of work, so much as documenting the work that has been done]

Kathy: when you look at UX you look at the whole experience. It is unrealistic to take each SC in isolation.

<jon_avila> Agree with Kathy. Also definition should also include maintaining users abilities not just improving them.

<Zakim> Rachael, you wanted to say we can include the explanation seperate from the "evidence for" statement

Rachael: I support the spirit of what Brooks has suggested. I think we need to be explicit about the exit criteria. Here is Rachael’s suggestion:

proposed language: Accessibility support documentation that provides 1) evidence of successful support for SC added to WCAG 2.1 with platform, user agent, or assistive technology dependencies is available for at least two technologies with at least four platforms (operating system/user agent/assistive technology combinations) and 2) an explanation of immediate user benefit derived from SC added to WCAG 2.1.

<Kathy> Rachael proposed language: Accessibility support documentation that provides 1) evidence of successful support for SC added to WCAG 2.1 with platform, user agent, or assistive technology dependencies is available for at least two technologies with at least four platforms (operating system/user agent/assistive technology combinations) and 2) an explanation of immediate user benefit derived from SC added to WCAG 2.1.

<david-macdonald> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria

Katie: each SC had requirements to come into existence. Let’s point to the work and evidence we’ve already created in the creation of the SC.

AWK: But we need quantification.

Katie: For the user benefit…”Success Criteria shall:

Address a situation where a user with a disability will be disproportionately disadvantaged (as compared to a user without a disability) if the criteria is not met.

<jon_avila> WCAG 2.0 implementation summary https://www.w3.org/WAI/GL/WCAG20/implementation-report/results

Katie: In the exit requirements for each SC….state the user benefit in prose

Michael: What we did in WCAG 2.0, we did not try to do this at an SC by SC basis. We were not requiring documentation of each SC.
... we are over interpretting what really happened in WCAG 2.0.

<laura> So we don’t need 2 technologies for all SCs?

<lisa> +1

AWK: should we remove the part that says “at least 2 technologies”?

<Joshue108> for the chicken and egg it would be great if we could

Michael: yes, this was not the requirement for WCAG 2.0

<laura> +1

<Joshue108> if we could demonstrate userneeds being met substantially

<jon_avila> I think what the accessibility with two technologies meant is that it was supported on Windows with IE and Mac with Safari, etc.

<lisa> we can vote to take out 2 technologies

<Alex> Y of which must be based on a mobile operating system and Z of which must be based on a desktop operating system

Alex: 4 platforms where 2 are mobile and 2 are desktop

Bruce: break exit requirement 3 into bullets

<shadi_> suggestion: [[Accessibility support documentation [3] that is available for at least two technologies, and provides evidence of successful support for SC added to WCAG 2.1 with platform, user agent, or assistive technology dependencies with at least four platforms (operating system/user agent/assistive technology combinations);]]

AWK: Accessibility support documentation [3] that provides evidence of successful support for SC added to WCAG 2.1
... bullet 1: with platform, user agent, or assistive technology dependencies is available

<jon_avila> q

AWK: using at least four platforms (operating system/user agent/assistive technology combinations);

<lisa> this might leaves cogontive and low vision in the cold if it doesnt work there well.

<lisa> part of our mandate, at least as much is to include cognative, as well as lowsivion. this doesnt make any more sence then to say lets leave stuff out if it dosnt help coga ad low vision

<lisa> we havent thought put the implications

Kathy: only require 1 mobile platform

<lisa> big -1

<lisa> big -1

AWK: I think it would be a mistake to put into place an SC that can only be done on iOS

<lisa> this might leaves cogontive and low vision in the cold if it doesnt work there well. part of our mandate, at least as much is to include cognative, as well as lowsivion. this doesnt make any more sence then to say lets leave stuff out if it dosnt help coga ad low vision

<chaals> [There are places where iOS is not a realistic option for most of the market]

<gowerm> oops

<gowerm> +1 to Lisa

<laura> +1 to lisa

<shwetank> +q

Lisa: making additional exit requirements for each major mobile platform is making mobile more important than coga and lvtf.

<Ryladog> +1 to lisa

<lisa> it will creat a huge net loss for accessibility

<Zakim> alastairc, you wanted to talk about example which is affected by separating mobile requirements

<laura> difficult to hear Alastair

<lisa> +1 to cant here

Alastair: zoom for low vision is written an SC from a content perspective.

David: there are some SC that won’t apply to mobile. And requiring more than 1 mobile OS is too much at this time.

+1 David :)

<laura> can’t hear David

<lisa> i have to join aria soon

<Zakim> gowerm, you wanted to say that any of our SC have restrictions given the considerations, whether those restrictions be for disability types, user agents, ATs or platforms.

<alastairc> alastairc: The benefit of the Zoom SC is not possible through mobile, but the whole concept is enabled by responsive web design, which was enabled by mobile.

mgower: we should not apply two specific mobile platforms (iOS and Android) to all SC.

Kathy: If we require iOS and Android…we will be taking out WCAG 2.0 SC
... we are not just focused on mobile, we are looking at touch screens and smaller (that desktop) screens, this includes tablets and touch laptops

shwetank: On mobile. I come from india. Primary means of access to the web is mobile where I come from.
... i’m concerned if we just say 1 mobile, there will be many important sites that will only test in iOS, and in countries where Android is the primary platform, most of these sites won’t work.

<Zakim> MichaelC, you wanted to remind CR is about testing implemntability, not the widespread implementation we do hope to also get

<chaals> [+1 to Michael]

MichaelC: Purpose of candidate recommendation is that they CAN be implemented, not that they have been implemented.

<Zakim> jasonjgw, you wanted to discuss briefly wider context of CR exit criteria.

Jason: agree with Michael
... what we are tyring to establish is that WCAG 2.1 can be implemented in an interoperable fashion and that concrete benefits exists for users (and that this addresses accessibility barriers). There is a larger context of public review and W3C review.

<JF> +1 to "concrete benefits exists" as opposed to "immediate user benefits"

<AWK> Accessibility support documentation[3] is provided such that:

<AWK> Evidence of implementability for SC added to WCAG 2.1 with platform, user agent, or assistive technology dependencies is available

<david-macdonald> I needs more than just documentation, it needs to "work"

<gowerm> +1 to David. I'm confused by that opening phrase.

Documantation is provided for at least four platforms (operating system/user agent/assistive technology combinations) 2 of which must be based on desktop operating systems

<alastairc> Just to point out, I can cynically read it as saying it has to be documented, not that it has to work...

<Wilco> +1 to John's concern

<alastairc> +1 to Rachael's wording above (10:04)

JF: concerned about not realistic to require on both Android and Ios at this time.

Alex: 4 implementations - could be 2 on 2 platforms…..or 1 on 1 platform and 3 on another platform.
... at least 1 mobile and 1 desktop!

+1 Alex

<Ryladog> +1 to Alex

<jnurthen> +1 to Alex

<chaals> [I like Alex' proposal. I think setting a formal bar too high is not helpful, but we should continue to be mindful that we need to demonstrate likely successful useful interoperability]]

<gowerm> At least four working implementations (a unique combination of operating system/user agent/assistive technology), at least one of which is mobile or touch, are documented

<AWK__> Accessibility support documentation[3] is provided such that:

<AWK__> Evidence of implementability for SC added to WCAG 2.1 with platform, user agent, or assistive technology dependencies is available

<lisa> big big -1

<AWK__> Documentation is provided for at least four platforms (operating system/user agent/assistive technology combinations) one of which must be based on a mobile operating system and one of which must be based on a desktop operating system.

<gowerm> How about: At least four working implementations (a unique combination of operating system/user agent/assistive technology), one of which is mobile or touch, are documented.

<lisa> yes

<laura> Agree with Lisa. Huge ramification.

<bruce_bailey> scribe: bruce_bailey

<allanj> What is a mobile platform? cell phone (what minimum size)? tablet (minimum size)?

AKW: one of the differences in past between A and AA was number of implimentations

Lisa: This is a decision in effect to downgrade controls from AA to AAA because it will not work for mobile
... it is imperative to support SC for coga

<lisa> it might work later

lisa: so this change would have dramatic poor effect

Kathy: is goal to demonstrate that mobile is possible?

<chaals> [+1 to accepting a touch-based implementation on a tablet with windows as a "mobile" system]

AWK: Well, if cannot find even one, we may be over reaching?

<Zakim> JF, you wanted to remind what shwetank said about how mobile is often the primary OD for many users...

Discussion about new version of Windows being mobile platform

Kathy: Suffice is like iPad Pro. I am looking for definition for mobile operating system

<Zakim> gowerm, you wanted to say At least four working implementations (a unique combination of operating system/user agent/assistive technology) are documented.

<david-macdonald> +1

Windows 8+ could be considered mobile

<gowerm> At least four working implementations (a unique combination of operating system/user agent/assistive technology), one of which is mobile or touch, are documented.

MikeG: leaving mobile discussion, asking for clarification around word "documentation"

AWK: Goal is for four distinct implimentations

MikeG thinks his suggestion for 4 implementations works for this issue

<gowerm> At least four working implementations (a unique combination of operating system/user agent/assistive technology) are documented.

MikeG think we can just say touch or mobile or small screen

JF: Does not like insertion of "assistive" with platform as muddies expectation

AWK think working edit draft in progress fixes that.

Lisa: Issue with removing coga SC is still of great concern

<shwetank> +q

Lisa: Coga support better right now on desktop than mobile

Micheal Cooper: To modify comment earlier, 2.0 expectation was for two platforms, did not have to be the same two platforms for all new SC

<Ryladog> +1 to Michael

MC: OTOH we also have requirement for two clean 2.1 AA implementations, so that might confound this somewhat

<jasonjgw> Perhpas we're back to "the intended benefits of each SC will be taken into account in choosing the platforms under which it is tested" proposal.

MC: We need to find sites that conform at AA, but with 2.0 it could be that SC were not applicable
... An SC not being applicable passes 2.0 (and would 2.1) but the way we make up for that is to have separate exit CR for all new SC

<Zakim> steverep_, you wanted to say any requirement to work on mobile must be specified in normative WCAG, but just documenting is fine

SteveR: Big difference between requiring documentation and there being sufficient accessibility support there is

<steverep_> From the definition of accessibility support: "The WCAG Working group and the W3C do not specify which or how much support by assistive technologies there must be for a particular use of a Web technology in order for it to be classified as accessibility supported."

<jon_avila> I think the main point of the exit requirement is that that a page/site can pass WCAG 2.1. So if zoom without scrolling can't be supported without adding a resize widget then we need to have an exception.

SR: We are deliberately open ended with the definition for accessibility support

<Zakim> shadi, you wanted to ask about mobile-specific requirements

SR: I have no problem with requiring one mobile implementation, even as not ever SC works on mobile

Shadi: If there are SC for contrast or spell checking that are not available on mobile, that is okay because the SC are technology neutral
... OTOH we have new SC developed specifically for mobile, so we might have conditional testing for those

<Jan> -q Jan

<Jan> +1 Shadi

<jasonjgw> I think my proposal is in line with Shadi's.

<JF> +1 to Shadi

<Ryladog> +1 to Shadi

Shadi: It is bit up in the air if some of the new SC are applicable to mobile

Brook: Concern with current drafting language being worked

Brooks: The proposed term "implementability" not as good as just saying "it works"
... Cannot skip proving that SC work because ties to our credibility

AWK: Summarizing that SC techniques and exit criteria are related
... No one is saying SC must work everywhere

MikeC: If we can demonstrate that SC is possible, but cannot find more than one platform, so we skip the SC -- could have consequences

MC: It could well be okay that 2.1 is just demonstration of proof of concept, and so still important to publish

<wilhelm> +1 to Brooks. What we decide here will be part of legislation, needs to both work and be _useful_ to real humans.

MC: Some developers holding off until we codify something.

Shwetak: We can not that support is not widespread

DavidM: Seemed to really upset to say "mobile" so maybe we just talk about small screen and touch?

Kathy: We really do not what to go back to what we mean by mobile.

DavidM: Mobile does not exist, but mobile is everything!

<lisa> great, mobile is core, cogantive is not

AWK: We need to define implementation test for the new SC, for example concurrent gestures.

<Joshue108> Lisa, no one is saying that

<gowerm> AWK, can you please investigate having some folks in the room using WebEx to improve room mic coverage?

AWK: Please mark yourself present

<vivienne> present

We will be doing one IRC session per day.

Dinner

JF: discusses evening plans

break for 20 minutes

<lisa> i need to go to aria on the hour. can we aviod any resultiutions that affect coga?

<lisa> i need to go to aria on the hour.

<lisa> ie now

AWK: Still working on 1st agenda item

<lisa> i am in apa now

JF: do we have resolution

<lisa> so please do not pass anything which affects coga

AWK: shares where he thinks we are with Implementation Critera

CR Exit Criteria

AWK: We agree that we want the SC to work for people (end users)

<lisa> note we agreed not to pass reslutions that effect coga when i can not attend

AWK: If is possible for techniques to meet SC and end user can benefit, that meets the big picutre idea
... We could have an SC that has no mobile support
... In aggregate though, we could demonstrate that all new SC work on some platforms
... End user might complain that we have not demonstrate all 2.1 SC work on a particular platform

Katie: Does not work YET

<vivienne> +1 to AWK's idea

AWK: Out exit criteria addresses that by having requirement for 5 conforming websites

AF: asks for other concerns

JF: Wants support on mobile platform for mobile SC

Kathy: Example of SC for touch makes no sense to test on a desktop configuration

<AWK> -jasongw

<shadi> +1 to Kathy

Kathy: We cannot just cite to original task force source because so many have changed

JF: Should our exit criteria reference the two that mention touch?

<JF> while noting that it may in fact be less than or greater than 2...

Jason: Saying that the platform selected will take into account the intended benefit of the SC should be on an SC basis
... We could say that the platform selected will be appropriate for the demonstrating the accessibility support

AWK: Do we need to be explicit about the choice of platform when we think that will happen organically?

<Glenda> +1 good approach

AWK: Or do we need to have something in the first or third exit criteria?
... Proposes to take another pass at drafting the specific phrasing, and post to the wiki and/or the list and we will finalize tomorrow.

Kathy asks if that might not end up causing us to put exceptions in the touch-oriented SC

AWK discusses that the exit criteria testing might also indicate that an SC is blocking

Kathy thinks this points back to Lisa's concern that some coga SC might not be implemented on mobile platforms

<laura> We will be dropping SCs if mobile implementation is a requirement.

AWK points out that with 2.0 that there were platforms were conformance was not possible

Discussion of cow paths versus paved versus gravel...

JF: Content on hover example where we really need to be sure to test on mobile, even as keyboards can be added

<laura> Josh, I remember it well :-)

Glenda points out that this is a point release, what worked for 2.0 is fine for 2.1

<Zakim> steverep_, you wanted to offer that perhaps just specifying that the 2 implementations for each SC must conform in a positive manner, i.e. not through exceptions, lack of

Kathy points out that we still following cow paths rather than pushing the envelope with how we are proposing to proceed

<Joshue108> +1 to a positve statement

SteveR: Clarifies that implementations need to be possible and positive. Demonstration is not proven by invoking an exception.

<alastairc> So for zoom, the SC says you have to zoom to 320px. For a mobile device that *starts* at 320px, would that be a default pass?

AWK: Clarifies that this is the case, as was with 2.0.
... 2.0 example was that we required video with captions, not that site avoided videos
... We seem to have a reasonable way forward.

Jan: Still seeing a lot of ambiguity around mobile and what we mean by that.

AWK: Thinks next draft will not have mobile in exit criteria, and not in SC text
... Our habit individually resort to using "mobile" as shorthand

Working through public comments

AWK: lets work through easiest ones first

<AWK> https://lists.w3.org/Archives/Public/w3c-wai-gl/2017OctDec/0313.html

Content on hover or focus

<Joshue108> thanks for grouping them like that Andrew - very helpful

<lisa> note we agreed not to pass reslutions that effect coga when i can not attend

<lisa> i cant not malti task

AWK: confusion on what hover means
... reviews SC text in draft

<laura> Success Criterion 1.4.14 Content on Hover or Focus: http://rawgit.com/w3c/wcag21/master/guidelines/index.html#content-on-hover-or-focus

AWK: currently 3 bullet points, one with two items

Katie offers to paraphrase:

<steverep_> What issue are we talking about?

Comes from LV task force

Main idea is that the triggering content not be obscured when the pop-up is activated

<laura> @steverep is the SC Manager

AWK: Example is where hover pops up a definition for a trigger word, the definition covers something else on the screen, but it must not cover the word being defined.

<Joshue108> I dont know which one we are on..

<Joshue108> 552?

<jnurthen> 1.4.14

<jnurthen> not looking at a specific comment right now

<Joshue108> ok, thanks James

<laura> http://rawgit.com/w3c/wcag21/master/guidelines/index.html#content-on-hover-or-focus

AWK: so Katies example is the first bullet

<laura> Understanding Content on Hover or Focus: https://rawgit.com/w3c/wcag21/content-on-hover-or-focus/understanding/21/content-on-hover-or-focus.html

AWK: The second bullet is that moving the mouse pointer to the new pop-up text must not cause the pop-up text to disappear

Katie gives an example

AWK: Third bullet is a requirement for supporting keyboard accessibility as well

<Zakim> steverep_, you wanted to ask if I needed to answer something? and to say the intent of the 3rd bullet has been a bit lost and I submitted an issue to fix it

AWK: Exception is for things like the default legacy title tool-tip behavior.

SteveR: Point of the exception got lost a little bits, so I submitted an issue to try to resolve that.

JamesN: If this is important, then we should not have the exception.

<laura> Agree with James. If it is important we shouldn't have the title exception.

Jason: Example is that changing a custom tooltip to Title fixes some things but actually makes the behavior worse for everyone.

Jason would like to understand the interaction between this new SC and the current Zoom SC and does that complicate things or need to be added as an issue?

s/Jason: If this is/James N: If this is/

<lisa> https://w3c.github.io/personalization-semantics/#semanticProperties

AWK: James issue is 471 and similar comment in 491

Glenda: The rational for the exception is to get at the gap that the authors have control over. We are making progress.
... As a task force, we focus on the problem in the right place.
... We don't want to ask a million page developers to patch something that we really need only one browser developer to fix

MikeG: 4.1.2 is similar

4.1.2 says is really for custom developers, just following the spec is enough for most authors

<laura> The authors will have an easy way to circumvent the SC with the title attribute.

MikeG: we just ask authors not to create more issues or problems

Jason: I read exception as delineation of responsibility. That page authors cannot be held responsible for bad browser behavior.
... The alternative is for authors to avoid tags that cause bad behavior, and there are arguments on both sides, but these are popular features.
... We can also work on prompting the browser developers to improve their behavior.

Alastair clarifies that the poor behavior still happens.

AWK: If you have a link with a title attribute, are we requiring additional work from the page author, or do we keep the exception?

Alex reminds us that with WCAG 1.0 and early 2.0 we had techniques with "until user agents" clauses.

AWK: Authors will take advantage of escape clause indefinately.

Kathie: This is a temporary clause. Overtime, need will go away. Example is 3D environment where this is certainly being addressed.

Glenda: Confidence that browser developers are addressing this. We no longer have the uphill battle we had years ago with 1.0 and 2.0.
... Advantage with the LV SC is that they are visual and easy to demonstrate to browser developers.

Glenda gives example of keyboard focus being hard to see is easy to demonstrate to developers, and conference like this makes those opportunities easy.

Jason: Best thing we can do practically is demark author and developer responsibilities, while continuing to work on browser developers.

<Zakim> alastairc, you wanted to say that it isn't hard for a tester to recognise a title attribute.

Alastair: It is pretty easy to recognize that behavior is from title, so maybe we make exception just for that attribute?

James: Embed can have similar behavior

Discussion that "man-on-street" assesment different than source code examination possible with resources provided as a professional evaluate.

Jame agrees that if you have source code, you can tell it is base on title attribute behavior.

AWK and James and Glenda discuss edit on github

<jnurthen> Persistent: The additional content remains visible until the user dismisses it or its information is no longer valid.

SteveR would replace that for 3rd bullet

SteveR: 2nd bullet can stay the same, with persistence folded into 3rd bullet
... 2nd bullet should Hoverable instead of Hover.

3rd bullet should be about persistence rather than than keyboard focus

Wilhelm: Gets much easier for browser developers when one can demonstrate end-user effects, and this is an example of that.
... The browser developers like to leverage good effects web developers and page authors

<wilhelm> https://www.w3.org/TR/html-design-principles/#priority-of-constituencies

Wilhelm is not sure if having the exception or not is the better plan

<lisa> im back

<gowerm> can someone paste it in?

<lisa> :)

AWK polls to ask if people like the text.

<jnurthen> Persistent: The additional content remains visible until the user dismisses it or its information is no longer valid.

<Ryladog> Persistent: The additional content remains visible until the user dismisses it or its information is no longer valid.

<Glenda> +1 to Steve’s proposed text change

<jasonjgw> The suggested text plainly addresses the issue.

<Zakim> wilhelm, you wanted to comment on browser vendor decision processes

<Zakim> Joshue, you wanted to say rotating the mic may be good.

<gowerm> +1

<jnurthen> Commenter agrees it addresses the issue raised.

<steverep_> "Hover" becomes "Hoverable" and "Focus: ..." becomes "Persistent: The additional content remains visible until the user dismisses it or its information is no longer valid."

<Jan> +1 to Steve's proposed text with the idea of replacing "its" with "the additional content" is no longer valid?

AWK checks that people okay w/ hover -> hoverable

Looking a comment 552

<laura> +1 to Steve’s proposal

AWK: Commenter just asking if their understanding of SC is correct. We think so.
... Issue 449 is SteveR
... What is resolution to issue?

SteveR: Can we remove re-positioning caveat?

AWK and other discuss that caveat is needed for very large triggers

<steverep_> Having a tough time hearing Alex or Katie

something has to be covered. Katie agrees that important to retain.

JF: This could also apply to feasible for mobile implementation.

AWK if allowing for repositioning is acceptable. SteveR is still concerned. Point for LV is see the trigger. If hover text cannot be moved off the trigger, we have not solved the problem.

Katie: Why would removing the option never be acceptable?
... Having more options allows the SC to be met. Agrees that repositioning might not be the preferred approach.

SteveR: Right now 3 options, but if I cannot see trigger, how can I move the content to make it readable?
... Users with low vision have trouble moving things around anyway.
... The option to awkward moving things around is not really providing accessibility.

<Glenda> I agree with Avila, that we have to allow for repositioning (at this time)

<chaals> [+1 to Jon. Consider an image as a trigger, which is zoomed out to be bigger than the screen]

<JF> +1 to Jon.

Jon_availa: With supporting zoom, need option for repositioning. Just closing something does not address the problem either.

Jon: Point is to have the option to see trigger and pop-up content side-by-side.

<laura> yes

<alastairc> +1 to Jon, both can be big even when not zoomed, thinking of editing interfaces especially.

Multi-way discussion regarding benefits of different options.

JF: ability to reposition might not be the best option, but might still provide better usability than not having the option.

MikeG: Asks if we really need an option to dismiss the pop-up content?

<Zakim> chaals, you wanted to talk about images as a use case for repositioning

Chaals: Use case of graph, with long textual description of the graph.

<gowerm> Bruce, I was saying the opposite. i was saying that I think we need to have an ability to dismiss as a requirement always; not have it so it is only listed as an "or" in Visible Trigger

This is example of LV user wanting to show as much of the graph as they can, with as much text as they can. Repositioning is useful.

<chaals> [+1 to both close *and* reposition. More importantly, close MUST be possible, even if you cannot reposition]

Rachael: The underlying issue is that probably we want ability certainly to close. Should this be an OR or AND.

Katie: We want both features

Chaals: As phrased, the SC does not provide both - an implementation that would not enable closing, but does enable repositioning, would fulfil the SC as currently written (which is bad. Although hard to implement I suspect)..

<gowerm> Just add in a requirement for an ability to dismiss

<gowerm> Dismiss: The additional content can be dismissed by the user

<johnkirkwood> +1 to add ability to dismiss

Crystal: We have two different problems we are trying to solve with this clause.

<gowerm> Dismissable: The additional content can be dismissed by the user.

SteveR: There are multiple issues. Yes, keep the trigger but while also seeing the pop-up.

<gowerm> Then remove "be close or" from Visible Trigger

SteveR: The other two issues are different than that, so being able to dismiss the pop-up is important.
... The SC does not prohibit repositioning.
... The feature for repositioning is not blocking for the features we are trying to require.

JamesN: Re-reading, thinks the SC gets what we want.

<jon_avila> repositioning can be better because if you close it and move your mouse it may keeping coming up?

<allanj> +1 to close popup

AWK: Are we asking for two things, one of which is always done (close the pop-up). So the repositioning ends up being an extra feature?

Chaals: Agrees that closing the pop-up is certainly a critical feature.

It is hard to imagine a UI where one could move the pop-up but not close it.

Jon: Easy to imagine scenario where repositioning keeps triggering the pop-up.

Lisa: This is a coga issues, so ability to prevent the pop-ups entirely is important.

AWK: Thinks that is a new SC for 2.2 or silver.

<lisa> +1 to working though haha

<chaals> [+1 to Lisa. I think it is not entirely new and we should consider it. I also doubt that it is very hard to specify and implement...]

breaking for lunch, back to the room in 60 minutes

<laura> Won’t be able to rejoin in an hour. Hope to be back for some of the time tomorrow.

<laura> Bye.

<Ryladog> Scribe: Katie Haritos-Shea

<Ryladog> ScribeNick: Ryladog

AWK; Ready to go

AWK: Finish up HOver/Focus
... Issues for Hover/Focus
... Repositioned by the user. What we really were coming close saying is that we dont need to reposition

DM: Chaarls was saying - was good

AWK: In both cases closing is part of it.

DM: So you want to leave it up to the author to reposition?

AWK: Yes

<steverep_> cannot hear speaker

DM: I would say the author might not know. I think what Charles said is true

AWK: Magnification use case is going to be for all users

KHSL Jon has a good use case

<Greg> One accessibility benefit to repositioning is to reduce memory requirement.

DM: I woud like to fix the title element

AWK: Anybody else? Steve comment about Visible Trigger #499

Issue 499: concern about repositioning

SG: Repositioning

AWK: It needs to say repositioning for a specific goal

Issue 499 concern about repositioning

SG: It is much easier to escape it

MG: Do we even need a visible trigger?

Steve: Yes

MG: You can always dismiss it

Steve: No you cant always dismiss it

MG: There is another issue by GV where there is another loophole
... Move it without triggering it, without moving focus

AWK: Do we not want to allow the content that appears on Hover,

MG: No, that part is implied
... It is going to go away if it is not beinghovered over
... So either, it is gone or the pop-up doesnt cover the trigger in the first palce

Steve: You are still gong to want to be able dismiss it wiht the keyboard

MG: Putting off the trigger is not the best place for it

AWK: Jason

JW: You want to be able to disniss it with out moving focus away from the triggering content? If it is we need to specificy it

AWK: The first bulllet seems to do that
... If you are popping up content dont cover he trigger or allow that content to be closed
... So it goes back to MGs point
... I think that is the best option

<gowerm> Dismissable: The additional content can be dismissed by the user without moving the focus from the trigger.

AWK: You said dismissable?
... Are you suggesting to replace one of the bullets

MG: I heard Jason said that, I just wanted to capture it

AWK: I think that is what the 3rd bullet says

MG: I disagree

AWK: What is the scenario - thet the mouse hover needs to dismiss that additional content?

MG: Is that the one with the ability to close
... There is no scenario then

AWK: I dont think so

JA: Focus the trigger I want to keep that content open.
... I dont think we want to say. I think we need to add that. If you tab away the content goes awy so we have met that requirment. I dont think we want that

AWK: Content can be closed w/o moving content

JA: I would say the triggerig or the original content

AWK: I think that is covered by the 2nd and 3rd bulllet
... If you are focused withe the KB you dont want that content to go away

JN: I heard someone say they wanted a mouse user wanted another way to close itwithout just moving your mouse away. Is that correct?
... That is just saying another close button on every popup - that is not realistic

AL: A close button slows people down

CMN: Except when your popup is bigger that your screen space. Like what I suggested before
... If you want to move the popup and the underlying graphic is painful

DM: Before with the graph, were you suggesting that we want every popup to be moveable

CMN: It is a separate req, not as important as being able to dismiss it
... It is two req that arent related

DM: We cant actually redo

CMN: Its broken - split it up

Katie: And / or

CMN: Dismiss is critical.

DM: We need close in the main statement, and then the conditional bullets underneith that

CMN: I take Alexs point. In a simple on, it just disappears. You want a close button to just appear. That would be painful

AWK: We need to stop, no more Q on this

<steverep_> Discussion also involves issue 350: https://github.com/w3c/wcag21/issues/350

BB: I want to point out as we rphrase this - it isnt how we wrote exceptions in 2.0. Exceptions were not in the body

<Zakim> steverep_, you wanted to say the real issue is whether or not it is covered that the close/dismiss needs to be able to to be done without moving hover or focus

Viv: Does this apply to Mega menus?

AWK: Would this be a failure of this SC?

Viv: Because it obscures the content

<gowerm> I agree. It doesn't address that situation (which can be horrible)

AWK: But it is not obscuring the triggering content. It covers other content. So no for this SC

Viv: Mega menus obscures the content underneith and there is no way to dismiss that

CMN: But tabbing 50 times is a way. Bad implementation, but trying to write the Success Criterion to stop that happening is unlikely to be a successful activity in time to get benefit

Rachel: Isnt that what this last bullet point about?

CMN: No because when you dismiss you should end up where you started. Yes bad implemetation

Graphics Contrast

<alastairc> https://alastairc.ac/tests/gq/

Alistair: Graphics quiz

Graphics contast links for testing

Alistair: this is from the Understanding page
... if it conveys the same information, somewhere on the same page, not worried about that
... which of these are actually required for understanding
... there are quite a few graphics
... on the home page - a thin grey line didnt meet the contrast ratio

<AWK> Alastair's presentation: https://alastairc.ac/tests/gq/

<Joshue108> Do we have a screenshare for this?

Alistair: graphical each meaningful bit of the image in order for you to see what the pic is conveying
... for a magnet I need to see the tip at each end. For the arrow you need to tsee the outline and the currency
... more complex - line chart. Need to be able to see each line.
... not suggeting we need to test every instance. we can use continuity
... human vision we cn see things continueing
... gradients, I suggest the test method would be to remove the bits that dont meet the contrast

<bruce_bailey> http://alastairc.ac/tests/gq/graphics-contrast-quiz_2017-11-05.pptx

<bruce_bailey> slide 12 now

Alistair: cuts off the corner of the envelope symbol

<bruce_bailey> slide 13 of 20

<bruce_bailey> Simple Diagrams

Alistair: pie chart w/only the labels of the slices. ONly need to see the edges
...
... in the middle it is not applicable
... add a border around ant slice that doesnt meet the contrast

AWK: if the colors were above the ratio they could see the colors. You would see three things

Alistair: yo have multiple ways

Rachel: so the adjacent ones were distinct

Alistair: I think

Glenda: if you go to greyscale and you just get all the info

DM: I am guessing that black would pass on everything
... On the left

Alistair: yes you could do with just borders on the left

AL: Go one slide back, that gets rid of the subjectivity. 20 folks will give you 20 diff answers

AWK: alt text is the same problem

GS: it say equiviant

AWK: we havet decided what we can live with

Alistair: would you recognize

CMN: peopke can see it becasue they can see the envelope on the left

shwetank: People have badges today like FB

AWK: is it just about the visual appearance of it?
... What if I added borders?

CMN: There is some subjectivity

AWK: You wouldnt do that in min-graphs
... that is part of what is communicated

<bruce_bailey> s/sh: People/shwetank: People

Alistair: piechart would by default it would have other indicators

Katie: it would have other indicators

Alistair: yes
... groupings maybe. You can see the whole not the bits with in it
... I ahvent finished thinking about it

<bruce_bailey> slide 15 of 20

<bruce_bailey> Exercise 1 – How many graphics are in scope?

Alistair: FB image in the list of links. How many on this page would be in scope
... look at ones that dont have text
... as AD this is a FB screenshot

GS: I think it is pretty clear

GSL You missed one

GS: Potentially

Kathy: Down arrow?

CMN: mysterious

Kathy: we are talking about 2 diff things

AL: we dont have inactive

<bruce_bailey> Slide 16 adds 12 highlights (red border)

AL: in the original contrast in 2.0 has an exception for inactive objects

GS: I think so in mine

JN: Are these graphics or UI controls?

Alistair: it is both

<Zakim> bruce_bailey, you wanted to say maybe this still needs more work and to ask if exception can/should be moved into body of sc

Lisa: select half of the piechart and it has another indicator
... someone might not be aware it exists to even mouse over it
... we cant expect them to click on every aspect of the page
... low vision and aging - those unfamiliar with UIs
... I would put an icon there to identify there is something there

AWK: I think that is in response to what I was saying. Lisa, that is a point well made

Alistair: I was thinking about that in terms of groupings
... apart from missing a couple. I got reasonable agreement

DM: Going forward GS might not say that it is the graphic contrast

<lisa> only thing i can think of is maps where every aspect is clicable

GS: We could say evrything falls into graphics contrast if the author ha cpntroll over it
... If it is made in Photoshop would be in another bucket - if you built it from scratch
... If it ends up failing both because you dont know for sure - they will still go to try to fix it

DM: I would say if it is a UI conponent or not - two buckets

Lisa: I love this SC. every aspect is a separate control, I dont know how many pixels are in it

CMN: An example like slider with a color gradient from one to the end has to hit enough to tell there is a gradient

Lisa: 2 pixels over, so there has to be some kind of exception

CMN: I agree

BB: There is question form GV

JN: Graphics must meet for a disabled control?

GS: No

DM: It doesnt have to

<david-macdonald> https://rawgit.com/w3c/wcag21/graphics-contrast/guidelines/sc/21/graphics-contrast.html

GS: It is aUI component
... Here is the exceptions. Except inactive is conveed

JW: Look at the def of UI component - look at the cases that are problematic
... Incusion of SC proposal - should we merge the UI and graphics contrast criteria
... If there is confusion - that strengthens the case to combine them

AWK: My question for this FB one = what is it?

KW: Back FB - See More, down arrow it is conveying info

GS: I suggest let suspend belief - can you pass this fr anything that is identical

I do not thinkwe should not try to combine them now - in this room

many agree...

CMN: You combine them

GS: everything on there is a graphic. But is it essential for understanding

Alistair: everything on the FB was a graphic. inividual identifiers
... outline is a visual identifier

AWK: Wait, what?

<bruce_bailey> Testing icons

<bruce_bailey> Slide 17

Alistair: Testing icons, these in Word dont have words, so these are graphical
... we could have an exception. Some dont have an indicator that it is a graphical comp

DM: you dont have to say Nike anymore

GS: It doesnt matter - it is the same under both. It is going to roll back to 3.1

KW: So why did we do this

GS: Because we thought we could get there. But we probably cant
... Testing is not going to be worth it. Let be real about it. Let drop the 4:5 to 1

Alistair: visual identifiers is the key

<bruce_bailey> Testing more complex graphics

<bruce_bailey> Slide 18 of 20

Alistair: Testing complex graphics. Reasonably easy to do. With good labeling it is not that hard

<bruce_bailey> Floorplan of hotel

Alistair: can you describe what you are showing.

GS: The map of the conference rooms? Have you done the red outlines?

Brooks: Selected state?

Alistair: yes

CMN: contrast test is active vs inactive state

Alistair: no red lines, sorry. icons without text would use the graphics contrast

JN: Border around it?

Alistair: you could. I think that will cover the essentail exception

JC: the question, in native apps, alot of these UI are very customizable. MOst MAC toolbars allow for icon, text or both
... what about hte current view?

Alistair: how do you identify conformance

CMN: If you changed it, it is conforming

AL: apologies to folks on the phone b/c this require animation
... Red diamond - easy to do. Right? But, this red diamond it is an interactive cube
... has a different contrast b/c of the lighting. We perceive it is 3D light bounced off it different
... The calendar, the page is slightly clipped. 3D. Which part of the white

<lisa> +1 to using the webex screen share

AL: I have the same object showing off behind that background I chose
... Contrast is controllled by the lighting
... When you apply this to VR and AR - it throws this right off

GL: start with a default mode where you start

GS: Oreo cookie method. Pick the color of the CFC.

AWK: I wonder if one of the exception is the Essential. For the 3D it is essentail

<david-macdonald> new exception "The auther has control of the the background.

<david-macdonald> "The user has control of the backgound"

CMN: There are a things - Alex said what is critical about the calendar - it has good contrast. But the cube doesnt
... The cube you can - the calendar you can see it is a calendar.
... I think what you do is take Alistair's model, it might work in the real world

AL: I picked this angle for a reason. Am I testing all sides. There is no way I am going to need 3.1.
... On one side may 4.1 but not onthe other side

JC: Maybe what CMN is saying is - what is essential and what is a technology demo
... If you want it to be realistic. Your brain fills in quite a bit, But what is the final UI?
... It is a judgment call in the real world

CMN: Look at this cube from a known angle - yes your getting hard. You can tweek the cube. It think the things are solvable
... You can take it further - you can find the thing from this distance - your brain fills in enough of the pieces
... I am not sure what in here could ne rendered in a monochrome environment
... We should brain test harder, rather than except out VR

<Rachael> David: Can VR projected onto your own background be on the web? Answer: yes.

<Rachael> Ryladog: Just because it is hard, doesn't mean we shouldn't do it.

AWK: Talk about Silver in 4 minutes
... We wanted to highlight some of the challenges in contrats

<Rachael> scribe: Rachael

update on Silver Task Force

<jeanne> https://goo.gl/5Hczsu

<lisa> 1 am here..

AWK: Getting started
... Onto Silver

Jeanne: The slides are at https://goo.gl/5Hczsu

<lisa> thnks jeany

Shawn: Update on Silver. The motivation was to create a more flexible way to evolve. Last year we decided to adopt a plan to be more flexible.

The goals for silver fall into two buckets: Content and Process & Structure

Content should be easier and more inclusive

<bruce_bailey> This is slide 3 of 21

<bruce_bailey> https://www.w3.org/WAI/GL/wiki/Goals_for_Designing_the_Silver_Process

Process and Structure should be easier to maintain and update. Once it is done, it is a kind of living standard. It can be built upon as new technologies come about.

<bruce_bailey> slide 4

<bruce_bailey> Stakeholders Research Questions Literature Review Communications Engagement and Participation Research projects

Quick review: Accumulated list of stakeholders (a few hundred); We have a compiled list of research questions. We have a lit review going on. Trying to get more participation from a variety of communities

<bruce_bailey> slide 5

<bruce_bailey> Active participants include: Developers UX professionals Accessibility researchers Education (K-12) Social media People with disabilities The Silver Community Group currently has 54 members

We have a lot of active participants. Developers, UX researchers, educators, people with disabilities. We have a community group so members do not have to be in the W3C to participate

<bruce_bailey> slide 7

<bruce_bailey> https://docs.google.com/spreadsheets/d/128vPnCweXN9t4JBG7-AOeBhT-KquaWXcCsi3H-f8u94/preview

On the screen is a stakeholder map based on roles. Example designer, accessibility developer. The slides link to the whole map. Each role maps to how they use the accessibility standards/interactions

What stakeholders use the standards in what way. That way when researchers reach out, they can reach out to people in the roles mapped out. We want to ask the right questions to the right people.

<bruce_bailey> slide 7

<bruce_bailey> High Priority Research Question Categories Supporting people with disabilities Supporting stakeholders When organizations choose to produce adaptations of WCAG Understanding the guideline development proces

Jeanne: We came up with a long list of research questions. The link is available. We prioritized them because we wanted to approach academic and corporate researchers to partner with us.

<bruce_bailey> https://www.w3.org/WAI/GL/task-forces/silver/wiki/Research_Projects#High_Priority_Research_Questions

Categories: Supporting people with disabilities

Supporting stakeholders

When organizations choose to produce adaptations of WCAG

Understanding the guideline development process

<bruce_bailey> Slide 7

<bruce_bailey> https://www.w3.org/WAI/GL/task-forces/silver/wiki/Research_Projects#High_Priority_Research_Questions

Key Questions: How might we make accessibility guidelines easier to use?

How might accessibility guidelines address more types of disabilities?

How might we make conforming with guidelines more straightforward?

How might we make the process of keeping accessibility guidelines current achievable and timely?

How do we scope it? (Web content, native, platforms, hardware, where do you stop?)

<bruce_bailey> How might we make accessibility guidelines easier to use? How might accessibility guidelines address more types of disabilities? How might we make conforming with guidelines more straightforward? How might we make the process of keeping accessibility guidelines current achievable and timely? How do we scope it? (Web content, native, platforms, hardware, where do you stop?)

Our approach to Silver is a participatory design process. We are working with research partners, stakeholders, public outreach, Silver Community Group, and AG (particularly staff and chairs)

<bruce_bailey> slide 10

<bruce_bailey> Survey: How flexible are current standards in supporting emerging technologies? Case Study: What are the factors that determine effective (i.e. widespread) adoption of and compliance with a new set of guidelines? Survey and Interviews: How well does the current structure of W3C Accessibility Guidelines serve different stakeholder groups? Survey: Understand the current university curriculum for web developers with web accessibility in mind.

Shawn: We wanted to talk about some of the research projects right now. We have a survey on standard flexibility. We have a case study on factors that determine effectiveness

<bruce_bailey> slide 11

<bruce_bailey> Diary Study: Evaluate how usable the W3C Web Content Accessibility Guidelines (WCAG) are to web developers Literature Review: Adaptations of WCAG Survey: Usability of WCAG

We have diary studies going with developers on usability of WCAG. And more

<bruce_bailey> slide 12

<bruce_bailey> 80 articles currently in Zotero library: WCAG Content, Structure, Conformance, Testing WCAG Process: Creation, Maintenance, Communication WCAG Adaptation/Evaluation Game Accessibility Cognitive and Learning Disabilities Accessibility

The lit review contains 80 articles in a Zotero article

If you would like a link, let them know.

WCAG Content, Structure, Conformance, Testing

WCAG Process: Creation, Maintenance, Communication

WCAG Adaptation/Evaluation

Game Accessibility

Cognitive and Learning Disabilities Accessibility

We are looking for more literature. If you have articles, please let us know. These are research papers.

Shawn: Quick expansion. We don't want to duplicate existing research. The hard part is identifying existing research.

We have to go find research so we can read through and identify themes, ideas, etc that has already been covered.

We want anything people have already written about WCAG.

These include articles from scientific databases.

Jeanne: Zotero is a software program that academic researchers use to classify and annotate articles. Part of the reason it is not public, is because it has research papers that are not open to the public.

We can publish the citations.

<bruce_bailey> slide 13

<bruce_bailey> Survey and Interviews: How well does the current structure of W3C Accessibility Guidelines serve different stakeholder groups? This is a draft of the Task Force analysis, later, Professor McNally will be publishing a detailed report. Please do not publicize these findings until after the research paper is published.

Jeanne: We got one of our first surveys back. Pete McNally did a survey to UX professionals. How well does the current structure of the W3C WCAG serve stakeholder groups.

We have a link to the data. Our research partners share the raw data early before publishing but we do not publicize beyond the room.

Shawn: Plan for silver. Rough overview for the overall design plan. Split into 5 phases. There is a link to the overall plan. WE presented it at CSUN earlier this year but we've since added years and quarters.

<bruce_bailey> slide 17

2016-2017 Discovery. Next up starting now through next quarter is interpretation.

We will be creating personals, studies, and user stories for Silver itself.

<bruce_bailey> https://www.w3.org/WAI/GL/task-forces/silver/wiki/Design_Plan_for_Silver

Phase 3 will be creating ideas for solutions Q2 2018. Q2 2018 Phase 4 will include prototypes.

Phase 5 will start Q3 2018 and will be writing the first public working draft This is where the working group comes back. Jeanne and I are not in the calls but we are aware of the conversations of 2.2

<lisa> q

We don't have a strong opinion but if the AG decided to go to 2.2, then they would focus on that and the dates would slide.

<lisa> note ther is a que

Alex: IS the timeline what you can do or what you want?

Shawn: A bit of both. We had a shorter timeline but the research phase has slipped. This is our ideal timeline + reality.

Alex: Have you looked at a public policy timeline?

AWK: That has not yet been part of the calculations.

Shawn: There is a phase 5+. Silver does not end there. It is intended to continue. The updating process would happen after the first public working draft.
... Discovery, Interpretations, and Drafting are ongoing.

<bruce_bailey> slide 19

Jeanne: Outreach presentations: TPAC, CSUN 2017, MeetUps, breakout session at A11TO in Nov, CSUN 2018. We continue to look for outreach.

<bruce_bailey> slide 20

<bruce_bailey> International participants for diary study Distributing translated surveys to non-English speaking countries Additional literature for review

One of the key areas we need help with right now is outreach beyond the US. We would like participants for a 2 week diary study 2 from ASIA and 1 from EU.

We also have volunteers translating our surveys into non-English speaking languages. We would like help distributing these. We need more help reaching international groups.

We are also looking for additional literature for the review.

If you have run across relevant articles, please send them to us.

<lisa> note there is a que

Brooks: The question I have about the Stakeholders. Have you reached out to international regulatory agencies or policy makers. I know everyone would like to see this work become rule of the land, worldwide.

Is there anything we should take into account to get guideline into law.

<jon_avila> have you included this 2014 symposium research into account https://www.w3.org/WAI/rdsymposia

Shawn: We have had a number of people in policy creation recommended but we haven't asked them those questions yet.

<jon_avila> It seems like the needs of industry -- function standards that are flexible are different from what others are asking for about specifics on exactly how things have to be implemented.

Jason: You need to establish priorities among what people are asking for. Someone will ask for everything. How do you propose to establish priorities and recognize that you will have a specification surrounded by additional resources.

Have you figured out what needs to be addressed in normative vs accompanying documentation.

Second question is, WCAG is an outgrowth of Web Content, User Agents, and Authoring tools but no work is being done in the last two. How are your investigations addressing the total situation in these areas. How much do authoring and user agent elements need to be included?

I think those are important architectural considerations.

Shawn: Agree that prioritization is important. For first public working draft, we need to draw a guideline around what a minimum spec looks like. A lot of that will come from research but your point that what people ask for.

We need to look at fundamental issues behind people's requests rather than specific suggestions. Then we can prioritize that.

Jeanne: Help from this group. One thing we are planning, is we would like to hold a two day meeting to do design planning. We would like to hold it before 2018 CSUN.

We would like to do a lot of the problem solving and initial prototyping.

The other thing was including the user agent and authoring tools that are not being worked on. We see a place for those to be included but don't know how they should be. That is part of the structure.

We have two phases on research/discovery: The first is content and that will be ongoing. The other is structure and we are prioritizing that.

We are working on the box, then will worry about what goes in it.

David: When you are talking about structure, we are talking about the structure of Silver, not the structure of websites, correct?

Shawn: So its really around the information architecture or conformance model. As one example, there has been a lot of challenges getting SCs for Cognitive and Low Vision that run into the conformance model.

<lisa> i am back but it is not clear

We'd like to work on that. Also, the way the information is presented causes confusion.

David: Its the document itself the

Shawn: Looking at the document and how its laid out as well as the architecture of the document.

<Zakim> alastairc, you wanted to ask about process recommendations vs guidelines

alastair: Is there any directions on incorporating user design process into the standards?

Jeanne: that is something we are being asked for

Lisa: Lisa: One is dimension of stakeholders who use the guidelines. The other is people with disabilities. Is there representation from all the different sub groups (low vision, learning disabilities, etc)

Is there adequate representation across various disabiliites?

Is there collaboration across literature reviews?

<lisa> https://docs.google.com/document/d/1WcfVALVq8PS9CLXUuAfV9Op0wXvI2yJYedj5jO23GTk/edit?usp=sharing

We are putting together early documents/roadmaps for how to support people with COGA disabilities. That process might be interesting for Silver to look at. We are gathering feedback on that document so it may be helpful.

<lisa> can we see the pecent and bakedowns of staholders and sub disabilityes

<lisa> brakedown

Jeanne: We have a number of people with disabilities active on the taskforce, community group, and stakeholders. We have a research project identifying needs for people with aphasia. We are open to more people.

As to the literature review, I believe we are coordinated. We are using the COGA literature review.

Lisa: I think it is really important to be transparent what disabilities are being represented in the stakeholders. We should publish the breakdown of the stakeholders and make sure the various subgroups are represented.

We might also need to do some followup if there is a lack of any group(s) being represented and ensure we are as inclusive as possible.

As to lit review, I was not aware of any coordination. You may be looking at an out of date draft.

Shawn: We agree we want to be as inclusive as possible and we have flagged several kinds of stakeholders on the stakeholder map that we want to ensure we include. That includes people w/ disabilities but also developers with little accessibility experience.

We have these flagged so we can do the outreach needed to be inclusive.

<lisa> formal request to make the brakedown of representation of people with disabilities and their subgroup transparent

<lisa> and to include mental health conditions

Jon: One of the challenges I hear is that WCAG is a functional standard so it does not tell people how it has to be done. Industry wants that but then you end up with a lot of supplemental documents. These can be very overwhelming.

The how to meet document is a step in the right direction.

I also heard usability vs. accessibility. There is a line between the two that will have to be figured out.

AWK: Any final questions?

Wilhelm: The research seems to overlap with my own anecdotal research. The thing we've been feeling most closely. We have a normative spec that is normative enough to be legislation while still being applicable to all technology.

Are we staffed to address the competing needs of readability vs legislative.

Shawn: Staffed? No

We are trying to get many people involved to try to address these issues, get many perspectives.

Jeanne: We have more people joining the community group and we hope to get more people in to help with the writing.

AWK: The process of finalizing WCAG and having people work with it, has driven this conversation. Broadening the reach is going to help a lot. It needs to help a lot. If we can't do that effectively and folks affected won't engage, that will be an additional challenge.

Shadi: I was asking about positive comments to look at successes of WCAG 2. I understanding POUR doesn't help end to end process but I feel POUR gives a story. There are a number of things the group did right, and I think making sure we take those forward to build on.

Shawn: Agree. WE don't want to undo anything we did well

Going on Break.

<lisa> i need to join apa again after the brake. sorry

<lisa> sorry about that

Exit criteria

<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_CR_Exit_Criteria

<Wilco> AWK: Look at updates, this is what we have

<Wilco> ... Changes in #1 and #3

<Wilco> JF: Is "platform" right?

<Wilco> all: yes

<lisa> note I need to be in APA now

<jnurthen> "relies on"?

<lisa> sorry about that

<Wilco> AWK: Could go back to platform as in #3

<Wilco> ... Need to put OS back in there

<Wilco> James: Don't get what "Relies on" means

<Wilco> AWK: Part of the conformance req.

<Wilco> ... relies on a platform with touch screen support.

<lisa> this is confucing, and the sites that do things for coga often do not conform to everythi g else

<Wilco> Katie: One responsive site is not too much

<Wilco> ... could be designed for small screen, or a responsive site

<lisa> and all the old problem survive

<lisa> APA is about to statrt. I can not malti task.

<Wilco> Glenda: Move "is available" up

<lisa> and we had agreed not to make resultions that affect coga when I have a clash. this will

<Wilco> ... Much better now

<Wilco> Jon: What does it mean?

<Wilco> AWK: For each criteria with a dependency on OS or UA or AT, we should have documented evidence

<Wilco> ... we won't collect that for something dependent on the author.

<Wilco> ... there is a dependency of the environment for example with orientation

<Wilco> ... For icon contrast for example there is no dependency for OS

<Wilco> Jon: Just worried about AT dependency.

<lisa> and all the old problem survive

<Wilco> Kathy: So what is evidence?

<Wilco> ... We should remove it, we want all 20 of them

<Wilco> AWK: Not much extra work. Do people like it?

<alastairc> Lisa - I don't think it's too restricting now. Needs 2 implementations across platforms (not restricted by particular platform) per SC.

<Wilco> AWK: Objections to go forward?

RESOLUTION: Accepted by the group

<AWK> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_CR_Exit_Criteria

Timeouts

https://www.w3.org/WAI/GL/wiki/2.2.8_responses

<Wilco> AWK: First issue, does this include unsubmitted data?

<KimD> Where data can be lost due to user inactivity, users are warned at the start of a process about the length of inactivity that generates the timeout, unless the data is preserved for a minimum of 24 hours of user inactivity.

<Wilco> AWK: User scenario, for users that need more time.

<bruce_bailey> http://www.w3.org/TR/WCAG21/#timeouts

<Wilco> ... For lengthy forms. It does apply to shorter forms

<Wilco> AWK: Yes it applies to unsubmitted data in every field

<Wilco> Kathy: I'd want it to save after I've gone through the next field. Not after every keypress

<shwetank> +q

<Wilco> Chaals: You have to do a bunch of work just to set up timeouts. If you have a stateless HTML form, the data exists as long as the user has the data

<lisa> NOTE WE HAD AGREED NOT TO ADRESS COGA SC WHEN I HAVE A CLASHING MEETING

<lisa> (AT least that is what I understood)

<Wilco> James: So I have to watch every keypress and reset the timeout after every one?

<AWK> Lisa, we won't agree on any changes without you.

<Wilco> Glenda: Answer is that you don't have to save the data, you just have to warn the user

<AWK> Just developing comment proposals

<lisa> ah, ok

Yes.

The phrase "...unless the data is preserved" includes user entered data that has not yet been submitted.

<bruce_bailey> http://github.com/w3c/wcag21/issues/403

Kristina, thank you to you and the UMass team for your feedback. The updated version of this SC 2.2.8 does not include the ability to extend the length of time. The new language has been set at AAA because of the difficulty in accurately correlating and tracking user activity with server and client side activity.

<Wilco_> Rachael: We decided it was going to be AAA. Proposed response:

<Glenda> +1 to that response

<gowerm> +1

<Ryladog> +1

<marcjohlic> +1

<Wilco_> James: I think it would be a drastic change to break it up

<Wilco_> AWK: This may be one we could make progress with for coga

<Wilco_> James: Many designers will not like it

<Wilco_> chaals: It is implied you state the minimum timeout. Many sites say how many minutes you have

<Wilco_> Mike: I think we can include a note to acknowledge 2.2.1. You may also want to include a definition of user inactivity

<Zakim> gowerm, you wanted to say we can include a note about the existence of 2.2.1 Timing Adjustable

<Wilco_> Katie: I would work on a AA for coga

<Wilco_> Rachael: I think it should be AA, there are a lot of ways to make this work. We can define it by what a developer can control. We give flexibility. If they time it out without warning, they can save the data.

<bruce_bailey> +1 for having a AA timing SC

<Wilco_> Kim: It opens a can of warms. We don't always know the timeout, it can change per customer. Some customers require a particular timeout.

<Wilco_> Rachael: There is a qualifier due to user activity.

<Wilco_> Mike: I'm concerned about putting it in AA. For a basic signup application, if you put it in AA you fail a lot of sites that don't bother

<Zakim> chaals, you wanted to say when you logged in the timeout starts. I'm not sure there is a big problem there. And it is feasible to leave the data there and say "your session timed

<Wilco_> Chaals: You don't know the timeout when you logged in? That's when you have the state change. It is fairly feasable to put a statement on the page. You don't have to do a roundtrip to say you stopped accepting the data

<Wilco_> ... There are plenty of techniques to do it. As for failing sites of AA, yes, that is the point.

<Wilco_> ... Yes, sites that cause these problems should fail this criteria. People need to know how much time they have for a task.

<gowerm> There is a scale problem though. Why do you need to do that for a 4-field input form.

<Wilco_> Alastair: I'm not convince, if you open a page without login, it doesn't just disapear

<shwetank> +q

<Wilco_> Chaals: Correct, that's not a standard piece of HTML, people build this

<Wilco_> James: You could fail a simple form, if you have a time limit to stop automatic submissions. People do these things to stop fraud submissions

<Wilco_> Jon: I've used login forms where the CAPTCHA timed out. Maybe we should consider "after you logged in"

<Wilco_> James: The main thing, the 24 hours, the extra 4 make things much harder

<Wilco_> shwetank: For proxy browsers, you don't have that option. Set timeout works very different. There are complications there to consider

<alastairc> Clarifying my point: I don't think the simple case (a simple HTML form, no login, no previous step), would fail this as it is not timed-out. It might if you have a captcha that times people out, but then you warn them.

<Wilco_> chaals: We say 24 hours, if we change it to 20, is it an issue about the number?

<Wilco_> James: Adding an extra 4 hours, why not make it the same?

<Wilco_> AWK: Gregg suggested we change it to 20 hours.

<Wilco_> ... don't recall why it was 24, other than it is easier to remember

<Wilco_> David: The reason for 24 is because there is no mathematical calculation required to figure out when it happens

<Wilco_> Michael: We should come back once Lisa is back

<Wilco_> chaals: You could state when the timeout occurs.

<Wilco_> PROPOSED RESOLUTION: Accept response resulting in change to 20 hours (discuss with Lisa)

Label in accessible name

<bruce_bailey> http://w3c.github.io/wcag21/guidelines/#label-in-name

<KimD> 2.4.12: For user interface components with labels that include text or images of text, the name contains the text presented.

<Wilco_> AWK: The change is for images of text

<bruce_bailey> http://github.com/w3c/wcag21/issues/419

<Wilco_> ... We're not using "Accessible name" anymore. No longer relevant

<bruce_bailey> http://github.com/w3c/wcag21/issues/452

<Wilco_> AWK: Request the word "persistent".

<Wilco_> Mike: If people feel this has been satisfied, that's okay

<Wilco_> ... I'm fine, I will close the issue.

<Wilco_> AWK: Jan, don't agree, visible label might be an abbreviation.

<Wilco_> ... I think our response is you could do both

<bruce_bailey> http://github.com/w3c/wcag21/issues/557

<Wilco_> JF: There may be overlap with form purpose

<Wilco_> AWK: That wouldn't change the response

<Wilco_> chaals: Should add it is good to expand the abbreviation

<Wilco_> Shadi: I think it's not a good idea to only expand it in the accessible name

<Wilco_> ... expanding is a different criteria. We should separate. We should encourage expanding anyway, but only expanding in the accessible name is a good idea

<Wilco_> AWK: Would you mark dd/mm/yyy as non-compliant with WCAG 2

<Wilco_> Shadi: For AAA

<Wilco_> MC: I think MM is a recognised label

<Wilco_> Kathy: I have test page with beginning, middle, end. It works regardless

<Wilco_> AWK: Any objections to accepting? None

RESOLUTION: Response to 557 accepted and posted

Schedule adjustments

<Wilco_> AWK: EO is coming in tomorrow

<Wilco_> Michael: There is the what's next discussion, and also techniques on the agenda that may not be important for f2f

<KimD> https://www.w3.org/WAI/GL/wiki/Meetings/TPAC_2017#Agenda

<jnurthen> https://www.w3.org/WAI/GL/wiki/Meetings/TPAC_2017

<Wilco_> AWK: One discussion to have was around 2.2 / Silver, what are our thoughts

<Wilco_> ... We should get a sense what the group thinks

<Wilco_> ... There is also EO and also just getting stuff done

<Wilco_> Wilco: Could spend 20 minutes talking about ACT?

<Wilco_> James, Shadi, Glenda: Yes

<Wilco_> MC: We track public comments from WG comments, we don't process comments as formally as we used to. Up until CR the risk is less.

<Wilco_> ... It helps to address public comments first because they don't see what we're doing

<Wilco_> AWK: Can do ACT in a call ofter Nov 20

<Wilco_> Wilco: Thursday at 9, ACT will present what we're doing, everyone is welcome for an introduction presentation

<Wilco_> AWK: Vote from the group, we'll skip talking 2.2 tomorrow, go hard into comments

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)

Succeeded: s/to Brook/to Brooks/
Succeeded: s/that coga/than coga/
Succeeded: s/OD/OS/
Succeeded: s/AKW/AWK/
Succeeded: s/scribe:bruce/scribe: bruce_bailey/
Succeeded: s/COntent on Hover or FOcus/Content on hover or focus/
Succeeded: s/Jason: If this/JamesN: If this/
Succeeded: s/changing ALT/changing a custom tooltip/
FAILED: s/Jason: If this is/James N: If this is/
Succeeded: s/in 481/in 491/
Succeeded: s/exception just for that element/exception just for that attribute/
Succeeded: s/to John/to Jon/
Succeeded: s/provide both/provide both - an implementation that would not enable closing, but does enable repositioning, would fulfil the SC as currently written (which is bad. Although hard to implement I suspect)./
Succeeded: s/TOPIC: Issue 499 conscern about repositioning/TOPIC: Issue 499 concern about repositioning/
Succeeded: s/clode it /close it/
Succeeded: s/seoerate/separate/
Succeeded: s/Graphocs/Graphics/
Succeeded: s/way. Bad/way. Bad implementation, but trying to write the Success Criterion to stop that happening is unlikely to be a successful activity in time to get benefit/
Succeeded: s/Peope/People/
Succeeded: s/others/some other/
FAILED: s/sh: People/shwetank: People/
Succeeded: s/Sh: People/shwetank: People/
Succeeded: s/angel/angle/
Succeeded: s/peices/pieces/
Succeeded: s/essesntial/essential/
Succeeded: s/rrsagent, make minutes'//
Succeeded: s/Lots of things run on/You have to do a bunch of work just to set up/
Succeeded: s/??/shwetank/
Succeeded: s/Allistair/Alastair/
Succeeded: s/Greg suggested/Gregg suggested/
Succeeded: s/no calculation/no mathematical calculation required to figure out when it happens/

WARNING: Replacing previous Present list. (Old list: allanj, JF, shadi, jasonjgw, Glenda, alastairc, Makoto, MichaelC, Detlev, MikeGower, david-macdonald, Laura, KimD, Pietro, Alex, kirkwood, marcjohlic, Roy, Rachael, jon_avila, Kathy, vivienne, shwetank, johnkirkwood, Amanda_M, lisa)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ allanj, JF, shadi, jasonjgw, Glenda, alastairc, Makoto, MichaelC, Detlev, MikeGower, david-macdonald, Laura, KimD, Pietro, Alex, kirkwood, marcjohlic, Roy, Rachael


WARNING: Replacing previous Present list. (Old list: allanj, JF, shadi, jasonjgw, Glenda, alastairc, Makoto, MichaelC, Detlev, MikeGower, david-macdonald, Laura, KimD, Pietro, Alex, kirkwood, marcjohlic, Roy, Rachael, Judy, Crystal, Katie_Haritos-Shea)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ allanj, JF, shadi, jasonjgw, Glenda, alastairc, Makoto, MichaelC, Detlev, MikeGower, david-macdonald, Laura, KimD, Pietro, Alex, kirkwood, marcjohlic, Roy, Rachael


WARNING: Replacing previous Present list. (Old list: allanj, JF, shadi, jasonjgw, Glenda, alastairc, Makoto, MichaelC, Detlev, MikeGower, david-macdonald, Laura, KimD, Pietro, Alex, kirkwood, marcjohlic, Roy, Rachael, Greg_Lowney, Jan)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ allanj, JF, shadi, jasonjgw, Glenda, alastairc, Makoto, MichaelC, Detlev, MikeGower, david-macdonald, Laura, KimD, Pietro, Alex, kirkwood, marcjohlic, Roy, Rachael

Present: allanj JF shadi jasonjgw Glenda alastairc Makoto MichaelC Detlev MikeGower david-macdonald Laura KimD Pietro Alex kirkwood marcjohlic Roy Rachael Katie_Haritos-Shea
Found Scribe: Glenda
Inferring ScribeNick: Glenda
WARNING: No scribe lines found matching previous ScribeNick pattern: <Ryladog> ...
Found Scribe: bruce_bailey
Inferring ScribeNick: bruce_bailey
Found Scribe: Katie Haritos-Shea
Found ScribeNick: Ryladog
Found Scribe: Rachael
Inferring ScribeNick: Rachael
Scribes: Glenda, bruce_bailey, Katie Haritos-Shea, Rachael
ScribeNicks: Ryladog, Glenda, bruce_bailey, Rachael

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 06 Nov 2017
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


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.)