Accessibility Guidelines Working Group Teleconference -- 20 Mar 2018

<Glenda> Puesto at the Headquarters

<Glenda> 789 W Harbor Dr

<AWK> +AWK

<Ryladog> https://www.w3.org/WAI/GL/wiki/Meetings/CSUN_2018

<AWK> Call in info: https://www.w3.org/2017/08/telecon-info_ag-ftf

<AllanJ> scribe: allanj

Work on open issues

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

<AWK> Project view: https://github.com/w3c/wcag21/projects/2

808

StephenR is working on this.

awk: forbidding content on focus
... don't want to mark as resoloved until we have something to point to

<AWK> https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html

awk; this is the understanding document. it is out of date and needs revision.

content which can on pointer hover must be able to be triggered by focus

chuck: saying don't require it. seems commenter doesn't want it as all as a solution.

<AWK> Suggest changing bullet to: "Content which can be triggered via pointer hover must also be able to be accessed via thekeyboard."

<Joshue108> "Content which can be triggered via pointer hover must also be accessed by the keyboard

awk: there is disagreement. there are situational times when content should popup on focus and other times not.

<laura> +1 to following up with steve

RESOLUTION: follow up with Steve about proposed response and report back

807

https://github.com/w3c/wcag21/issues/807

ja: will follow up with steve for pull request for updated understanding on hover

<JF> we have a similar problem with the Understanding doc for 1.3.4 - it's still out of date when linked from here: https://www.w3.org/TR/WCAG21/#identify-common-purpose

805

https://github.com/w3c/wcag21/issues/805

gs: there is not one solution fits all for disabled elements. 'they' want color contrast on disabled elements. gives discriptions
... some want contrast, some not for various reasons. deferred to silver. take up in Personalizations
... perhaps have some symbol preceding a disabled element, etc. other ideas.

awk: jon aviala - how to distinguish between INACTIVE and DISABLED. sited shoe size example

gs: exempt specifically for DISABLED not "not selected"

joc: very nuanced.

<Zakim> Joshue, you wanted to say I dont know if this does belong in personalisation

jf: mgoweer - difference between read only and disabled

joc: would rather have something there in the UI to distinguish these types of items.

gs: will need some symbol (and word), too complicated within our time limit. need more discussion within lowvisin and COGA. was more a personalization issue for those who want indicators and those who don't

<Zakim> gowerm, you wanted to say ensure the typo is handled at the start of the draft response "some users won't to ignore"

gs: a silver issue.

mgower: typo won't ... should be want in lv section of response
... need to be programattically determinable, then personalization will chip in
... good response

bb: thought we were only using it for disabled. thought the terminology was more precise.

<Zakim> bruce_bailey, you wanted to note that 2.0 says inactive not disabled

awk: thought the same also. current language does distinguish between inactive and disabled.

<Zakim> Joshue, you wanted to ask remind us of what do we have in 2.1 on minimum contrast for disabled or inactive elements.

joc: reference contrast for inactive. is there any requirement for inactive elements.

bb: read only elements have the contrast requirement. it is not actionable.

gs: seems, it used to say disabled, but now it doesn't.

awk: what makes a component active? what is the active state. or it is active because it is not disabled.

gs: december version of 1411 - specifically called out 'active user interface components"

<AWK> https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

<Glenda> https://www.w3.org/TR/2017/WD-WCAG21-20171207/#graphics-contrast

present"

awk: changed 1411 to meet wording and definitions from 1.4.3

gs: its not about the selection state, its about can I even use this element. Need clarification in Understanding doc.

jw: ??distinction between inactive, disabled, not focused. Do we have definitions anywhere for these terms

<JF> +1 to having a clear definition of terms

jw: not selected, not infocus . Not entirely clear. Need definition to provide distinctions between these items

<laura> “inactive” is used in 1.4.3 without definition.

awk: signup button. until you enter email, then button is inactive. probably implemented with disabled property.
... with 5 step process, can't activate next step until current step is completed. that is inactive

<Glenda> And look back at the even earlier version of this SC at https://www.w3.org/TR/2017/WD-WCAG21-20170912/#graphics-contrast

<Glenda> Inactive

<Glenda> Disabled or otherwise inactive user interface components;

awk: then there is the aspect of 'not yet active'

<Zakim> gowerm, you wanted to say No one is confused by "disabled" so why not just use that instead of inactive? If we are going to use inactive as a synonym for unselected or unfocused, I

awk: for shoes example - shoes available, not selected, not available.

<Joshue108> +1 to Mike

mg: if we mean disabled should say disabled. need to define inactive, and read only, and unfocused.

<laura> Needs to be backward comaptable to “inactive” as used in 1.4.3.

gs: that is why we used 'inactive' from 1.4.3

awk: also used in 1.4.6

gs: need to fix in silver.

<Glenda> We need to stay with “ inactive user interface component” because that is how it is in 1.4.3 WCAG 2.0

joc: language has been an issue with 2.0. and we are bringing it forward.

awk: do we need definition for "inactive" or just add verbiage in understanding. there are examples in this issue - if you assume the steps are clickable.

<Joshue108> So who wants to take an action to work on drafting these definitions?

gs: need to parts to def. inactive as in text, and inactive as in UI component

<Zakim> gowerm, you wanted to say is it impossible to change 1.4.3 in 2.0 with a correction? IT doesn't change the meaning

mg: if we do 2.2 can we change language in 2.0

gs: NO!
... no def. do in understanding

khs: defs are always good for clarity

jw: add def, or add def but only applies to 1.4.11 (problematic), add something in Understanding
... preference is for def

<gowerm> To clarify, I did not say "if we do 2.2 can we change language in 2.0" I asked after 2.1 is released, is it feasible to consider changing SC language in 2.0

<bruce_bailey> +1 that best approach is add definition

<jasonjgw> +1

<Ryladog> +1

awk: straw poll, impacts on 143, 1411, 1413

<Joshue108> +1

<JakeAbma> +1

<JF> +1

<marcjohlic> +1

<gowerm> +1 I can live either way, but thinki definition is better. as katie says, we don't have to link in 2.0 SCs

<Glenda> +1 understanding

<AWK> +!

<AWK> +1

<Chuck> +1

<laura> +1 understanding

awk: in understanding glenda thru Laura

gs: anyone who wants def must write it.

<Joshue108> -1

gs: I am NOT writing it. adds confusion with 143

<Glenda> Glenda: And look back at the even earlier version of this SC at https://www.w3.org/TR/2017/WD-WCAG21-20170912/#graphics-contrast

<Glenda> [09:15am] Glenda: Inactive

<Glenda> [09:15am] Glenda: Disabled or otherwise inactive user interface components;

<Glenda> [09:15am]

gs: tried to get def in the document. the WG pulled out the wording.

awk: gs is right. define inactive. why is it not linked in 143, 146

<laura> listen to goodwitch we have been through this before.

<gowerm> Is there any reason you wouldn't just use "disabled" in the new SC?

gs: reads dictionary definition of inactive

<bruce_bailey> Change my vote -1. Agree with Glenda that defining "inactive" separately "inactive user interface component" might not be feasible.

<Zakim> gowerm, you wanted to say is using "disabled" and to say is using "disabled" in the new SC an option?

ac: inclined to not do anything about it. gets very complicated. do it in understanding!

<Glenda> then we are not mapped to 1.4.3 in WCAG 2.0

mg: can we use 'disable' rather than 'inactive'

awk: then a mismatch between wording in 2.0 and 2.1

<Glenda> 1.4.3 uses “inactive” and 1.4.11 is expanding 1.4.3 to extend to graphics

mg: vote to make new one clear and not perpetuate ...

<alastairc> Glenda - really it is applying to non-text parts of components, which are generally not graphics per-se... so I see it as expanding 1.4.3 slightly.

gs: had clarification, but it was tossed. Need to be parallel with 1.4.3. this SC is an extension of 143 must use same language

<alastairc> Note that the understanding doc for 1.4.3 doesn't even mention inactive...

ja: +1 understanding

<Chuck> +1 understanding

<laura> +1 understanding

<Glenda> +1 understanding

awk: define or understanding

<AWK> +1 understanding

<JF> +1 to understanding

<JakeAbma> +1 understanding, but only for now

<Ryladog> +1 to understanding

<alastairc> +1 understanding

<Glenda> inactive = unresponsive to user input

jw: definition - inactive in UI component ^^^

<gowerm> +1 understanding, but for God's sake let's stop using "inactive" in the future!!!

jw: in silver, flag to create defintion, so we don't go through this again

<gowerm> Grin

awk: mark as DEFER so it is taken up in silver
... mark issue as DEFER

gs: I will take this on in Understanding

RESOLUTION: defer issue to silver, clarify definition in 143, 146, 1411 Understanding.

awk: Glenda will take this
... 252 should get 251 note

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

763

awk: note that is 251 should also be used in 252

mj: if it makes sense in one should work in the other.

awk: use pointer gestures

<JF> +1 to that

<Joshue108> +1

mj: or pointer input

<JakeAbma> +1

RESOLUTION: note that is in 251 should also be used in 252. and change Pointer Gestures to Pointer Inputs in both SC

778

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

jf: this is editorial

<laura> you’re welcome, Jim.

awk: some defs are not full sentences, for reuse purposes
... definitions are intended to replace the term in SC text
... term TARGET will be changed.

<laura> https://www.w3.org/TR/WCAG21/#dfn-target

khs: take the def and add as a note to the SC

awk: think it's ok. if two object A and B of different shapes, inactive target areas. don't think having a note weakens the SC

<Zakim> gowerm, you wanted to say the definition uses the term "pointer actions". I am more comfortable for that being the word used in 2.5.2 and 2.5.1 than "input"

mg: the definition uses the term "pointer actions". I am more comfortable for 'actions' being the word used in 2.5.2 and 2.5.1 than "input"

awk: circle back to that

dm: the 2nd para is informational.

awk: any objections to proposed 778 actions

<AWK> https://github.com/w3c/wcag21/issues/778#issuecomment-374672047

RESOLUTION: Accept response as amended in https://github.com/w3c/wcag21/issues/778#issuecomment-374672047

763

mg: the definition uses the term "pointer actions". I am more comfortable for 'actions' being the word used in 2.5.2 and 2.5.1 than "input"

awk: no objections

<Glenda> https://github.com/w3c/wcag21/commit/3dd6d209ad9881301c4e7a00d4d57c55276b86b3

awk: updated response by MJ

Non-text contrast

gs: add active and inactive as appropriate in Understanding. with clarification for disabled

<JF> WFM

awk: instead of UI components that are inactive.... say UI components that not available for user interaction
... strike comments about Silver

gs and awk editing live and discussing wording

<alastairc> Not entirely following the audio, but if you have a button that is focusable, doesn't have the "disabled" attribute, but doesn't do anything, is that including in inactive?

<gowerm> I think that is just a non-fuctioning button, Alastair. It still works. it just doesn't do anyhting.

<alastairc> Then should it have contrast? I'm thinking about same-page links, or breadcrumbs for pages you haven't got to yet.

ac: disabled is a subset of inactive. reasoning for word choice

awk: links covered by 1.4.3 (text contrast)

<Zakim> Glenda, you wanted to ask about merging “inactive” info in Understanding into the master

<alastairc> "disabled" has associations with the disabled attribute, which is why some would consider it a narrower set of component than inactive.

<Glenda> <h4>Inactive User Interface Components</h4>

<Glenda> <p>User Interface Components that are not available for user interaction are not required to meet this color contrast requirements in WCAG 2.1. Due to the different needs and preferences of people with low vision and people with cognitive disabilities, a contrast requirement for disabled user interface components is recommended for future advancements for user preferences.</p>

<Glenda> <p>An interface user interface component is visible but not currently operable. Example: A submit button at the bottom of a form that is visible but cannot be activated until all the required fields in the form are completed.</p>

<Glenda> https://github.com/w3c/wcag21/blob/non-text-contrast/understanding/21/non-text-contrast.html

<Zakim> gowerm, you wanted to say editing by committee is a nightmare, but shouldn't you say somewhere very clearly that you are talking about "disabled" components? It used to be in the

mg: sad to see 'disabled' removed from the edits

<alastairc> gowem - there's one instance in 1st para above.

<laura> need to drop off the call now. bye all.

RESOLUTION: accept Glenda's edit to 1.4.11 understanding https://github.com/w3c/wcag21/blob/non-text-contrast/understanding/21/non-text-contrast.html

--- 15 minute break ---

--- back from break ---

awk: we will be resuming work on implementations. Review Exit Score Card

open item 10

<AWK> https://www.w3.org/WAI/GL/WCAG21/CR/scorecard

need a bit of work on 1.3.5 ID purpose

awk: look at 1.3.4, 5 evaluators, 2 evaluations agree
... important to have at least 2 evaluations in agreement. Chairs will be reviewing. Looking for clear path to agreement to canonical score of 2 or more
... add comments for passing or failing to help in agreement determination.
... comments important in Full Site evaluations.

<Joshue108> I'm goint to try an eval of 1.3.5

awk: need more evaluations on 1.3.5, and pointer both of them, motion actuation.
... still lacking agreement on many. please rereview items in RED in 1 evaluator and all evaluators

ack: j

<Zakim> JF, you wanted to seek clarity on the implementation examples for 1.3.5

jf: items that have rudimentary implementation. reference draft recommendations. have proof of concepts. but are not available at scale

awk: WG has to verify that solution provides positive end result across platforms and AT
... if it is custom or proprietary solution, but there is support then OK

jf: have a proof of concept, but not other implementations using the technique
... have found other examples in the wild for 1.3.4.

joc: testing 135. the proof of concept is spot on. but not anything else in the wild

<JF> https://a11y-resources.com/developer/adaptable-ui-personalisation#aui-field

awk: Do all of the implementation examples for 1.3.4 use autocomplete?

jf: link above for anther technique to meet 1.3.4
... it is a proof of concept

<Joshue108> I think the Athena example is kinda cool :-)

khs: are any of 1.3.4 using something other that autocomplete.
... is autocomplete sufficient in all examples. if we have no other methods to show, is that ok

awk: yes.

khs: if we release 1.3.4 and only 1 of the 2 bullets is implemented. is that OK

joc: it works. regardless of what we call it, it is useful for many.

jw: in 135, what is sufficient accessibility support to meet the SC.
... in 135 need accessibility support for each item in the SC
... level of implementation in 1.3.5 need to be looked at for each bullet.

awk: yes. 135 is at risk.
... in 134, 2 bullets. you can't meet 1 or the other. second bullet is an exception to first bullet. when the second bullet is no longer relevant, then they meet the first bullet
... provides explanation of new function 'foo' to meet the requirements of the SC.

khs: use pictures

awk: not necessarily. depends on new concepts and implementations.

khs: ok. just suggesting different name.

<Joshue108> I've added an implementation/eval test for Athena-ICT / 1.3.5 Identify Purpose

<Joshue108> works well :-)

jf: comes to what is asked for.... 'programattically determinable'... if that is done there are many options for output to the user. but first it must be programattically determinable
... its about the level of support.

joc: There is semantic support available and I'd like to see more examples, as it is impressive.

jf: it's complex. very explicit in using 'programatically determinable' in the SC. must look at the program

awk: our criteria is not just that it is in the DOM, must be more than data is present, something must happen because of the data presence
... lcan be additional enhancements to information provided to the use

jw: 135 refers to purpose of the regions. is the purpose in the aria vocabulary? some info is not available in aria-roles

<Joshue108> We have no implementations on the scorecard that have 0 evaluations, good job all :-)

jw: the purpose provide by aria semantics... is it sufficient to meet 134 and 135?
... may need to go beyond the level semantics available today.

awk: yes

jf: the gap in semantics that exists is what the personalization taskforce is working on

bb: do you have examples?

jw: with respect to regions, the may be some that are not covered by aria-roles. not sure of history. speculating

khs: something is a heading, is marked as a heading not a header or a footer. so user can choose what they want to see... main content and not header or footer or other combinations

joc: can script to provide many views based on available semantics

awk: more time to do more evaluations. look at exit score card and implementtion list

<AWK> https://www.w3.org/WAI/GL/WCAG21/CR/implementations

awk: anything with a 1 in the evals column is not sufficient. need more independent evaluations

<Ryladog> I'm in the middle of Ticketmaster for 2.2.6 Timeouts, finishing that first

awk: scorecard still needs a bit of work

all: working on testing

<AWK> Alastair are you there?

<david-macdonald> Rough Draft of WCAG2ICT for the 2.1 Success Criteria http://davidmacd.com/WCAG/wcag2ict-21-discussion.html

--- lunch now 1 hour break ---

back at 1:35

<Ryladog> Walmart failed for Text Spacing 1.4.12 - However, Penn State Accessibility HOME passed for Text Spacing 1.4.12 (http://accessibility.psu.edu/)

<Ryladog> How do I add this test to Implementations?

<Chuck> Scribe: Chuck

Resuming from lunch break

awk:

issue: 772

<trackbot> Created ISSUE-51 - 772. Please complete additional details at <http://www.w3.org/WAI/GL/track/issues/51/edit>.

ja: basic question is what is bold for font weight?
... complex issue, there is no standard for bold.

Issue 772

ja: change understanding document to include specifics.
... it's possible to utilize properties on fonts to come up with varied results.

<JF> scribe: Chuck

ja: definition of bold is up to typographer.

<AllanJ> https://github.com/w3c/wcag21/issues/772

ja: One can't objectively say bold is bold, it's currently a subjective determination.

awk: There may not be a bold variant for a font.
... This is affecting 1.4.3 and 1.4.6.
... What's the response?
... A desirable response is to say this is on wcag 2.0 success criteria and we aren't going to make a change to the success criteria or the definition, we can look at this later.

<JakeAbma> Note 1: CCS has set bold to be 700 as a numerical value but this doesn't guarantee a bold font face is chosen OR this is the right number for specific fonts as another, lower, number may also be applicable. Note 2: Bold font faces can also be present visible while 700 is not chosen as a numeric value, even normal/400 may look bold by adding CSS properties

david: had same question. Rely on the tester to make the determination.
... we could say something in the understanding document to offer guidance.

jim allen: we don't want to make this confusing.

katie: This has become more compicated. We have more fonts.

awk: suggest that this waits until we get 2.1 out.
... label it understanding, not label it silver.

RESOLUTION: label issue 772 for future understanding work.

jw: not an issue for now

awk: will write a response.

803

awk: this one is in favor of 1.3.4, but suggests that they don't like baking in the reference to html 5.2, instead it should be an appendix to wcag itself, or another document.
... If we were going to do this change, this would not be an automatic change we can make, we need a good argument for it, we wouldn't be adding to or subtracting from list in the process. What do people think?

<JF> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Implementations/JF/research

jf: thoughts: 1 commenter is a web chair. There are a number of tokens not directly supported by browsers. Why are we ceeding some criteria to an external group?

<Zakim> AWK, you wanted to say that the control gained from this change would also require breaking backward compatibility to use that control

awk: Understanding point on control, but 1) in order to use the control, if we want to take anything away, we will need to talk about backwards compatability. If we ref html 5.2, there's nothing to say that if we decide to edit the criteria, we could say to use these auto-fill tokens from 5.2 "except for this one...", "omit these three add these four", while providing html 5.2 as starting point?

jf: goal is getting a taxonomy. auto-complete is just a technique that works today.

awk: we could still do it, may not seem as clean and neat. We could add more later.

we have decided to not break compatability with 2.1, we have not made a determination on backwards compatability for 2.2.

jw: you would need a separate success criteria, you would be in the same situation. It's still a decision about a level of what backwards compatability means. It would also be open to make a decision that this is an area that needs to be addressed differently, it could be moved into a parallel specification or an appendix then rather than now. We are simply making reference to a fixed list of items and we are doing that by making normative reference to a specifi

c version of html.

jw: If the decision is to move to silver in 2-3 years, maybe that will be overcome by events.

jf: feedback I heard from people in silver, there is the possibility of having to deprecate some things. There was some discussion.
... tech is contantly changing, specs need to be dynamic.
... at some point we took those token values because it was a published taxonomy.
... whether we control it or let others control it is an architectural decision. We should pick what's on the list.

awk: we are deciding what's on the list by choosing the dated list.
... 3 possibilities for html 5.3, stays same, takes things off, adds things.
... What it seems like to me is we can get the same end result for 2.1 either way.
... What we could do in 2.2 is we can discuss if we can do anything that breaks backwards compabitility, we have opportunity to say we want to add tokens, and evaluate how it aligns with 5.3, 5.4, etc, or add separately.

jf: Now we are looking at two lists and that is not desirable.
... the other advantage to my mind by stopping pointing at auto complete we can pursue our longer term goals.

<JakeAbma> +1

david: I agree we should pull it into our standard.

davd: We are now in CR and we can't move them. I think pulling them in is going to give us more permanence.

david: optics is important.

awk: we will need to make an argument, I definitely would want it in the appendix.

shadi: were is 1.3.4 in the en. It is in the EN301549.

en 301 549

shadi: you are not changing the meaning of the success criteria.

awk: how will that go over with the director?

shadi: believes we can consider it editorial.

taking a moment to research documentation

<shadi> draft EN 301 549 v2.1 for review: http://www.etsi.org/deliver/etsi_en/301500_301599/301549/02.01.01_20/en_301549v020101a.pdf

<JF> https://github.com/w3c/wcag21/issues/426

awk and jf reviewing past documents.

jw: does anybody remember what Michael Cooper said in the past?

Katie: he didn't want it internal.

mj: I like the idea of the apendix

shadi: It's a matter of preference.
... rather than control.

katie: there are really rich taxonomy
... we should be using that.
... we could use access for all.

jf: we could do that, it's programatically determinable.

katie: having to put content on every element is a poor way to do this. Great weight on developers. It's going to push people from good things in the standard.

awk: everything done by a machine still needs to be done by a person.

katie: It could take a field and decide what meta-data to use.

david: there's pressure on us, real pressure.
... my personal opinion is if we cycle around for another cr it will be tough for us to get other things done.

awk: where does this list live? I prefer to reference it externally. One fewer thing to maintain in the spec.
... I hope it's something we could all agree there is a path forward that informs people to what we need to conform.
... more people are in favor of moving it in than leaving it out.

jf: I don't want to exit CR regardless, this is not worth causing us to exit CR.

RESOLUTION: working group decides to move the list into an appendix of wcag 2.1 unless that change contravenes cr status.

<AWK> David's starter pull request for this is @@d@@

issue: 806

<trackbot> Created ISSUE-52 - 806. Please complete additional details at <http://www.w3.org/WAI/GL/track/issues/52/edit>.

806

<AWK> trackbot, close issue-806

<trackbot> Closed issue-806.

<AWK> https://github.com/w3c/wcag21/issues/806

awk: 806 is about a bunch of stuff. Long thread.
... some suggestions about changing some things within normative text in wcag 2.0.

glenda: no

<AWK> https://github.com/w3c/wcag21/issues/806#issuecomment-373790425

awk: changing ceisures guidelines to seizures or physical reactions.
... 2.6 would become other modalities.

katie: each thing should identify what it is, not "other" or "additional", because it doesn't identify the category.

awk: change 3.1 from "readable" to "meaningful".
... at it's core, one of the questions is ... we could change the name of guideline 2.6 as it's a new one. If that results in better organization, that would give a higher level of control.
... chainging seizures to ... and physical reactions starts down a slippery sloap.

c /slope/slope/

awk: easiest solution is to say we aren't changing anything in 2.0 and shoe-horn in as best as we can.

jw: they all seem rational on the surface, ultimately a question of when to make them and how to proceed on 2.1.
... not in favor of leaving the 2.0 text unchainged under the strict interpritation that you can't change existing text. Given decisions are made up to this point I'm uneasy at making those changes now at the last moment. Maybe should be an issue for the next version.
... changes do seem attractive.
... at some point we will need to revisit the concept of making changes in this document.

<JF> +1 to Jason.

katie: possible to add physical reactions to seizures, but not necessary. Have every right to change name of a new guideline.
... should not change "meaningful".

david: p.o.u.r. is a good teaching model.

awk: for these particular changes, I would like to change as little as possible from the cr draft. I do find seizures and physical reactions appealing.
... if all we are doing is adding 3 words to guideline and description, we are not breaking backwards compatability.
... That would be the one I would change. As far as adjusting 2.6, we need a proposal for what that is.

glenda: I prefer we make no changes.

katie: Making things more understandable, I don't know why we wouldn't want to do that.

bruce: for physical reactions, is that a good characterization for not wanting animation on screen? Isn't that more cognative?

katie: more about vertigo.

bruce: I agree it's an improvement.

awk: Currently called Additional Sensor Inputs.

katie: guideline should describe it's contents and not include "other".
... "other" is not descriptive of what's there.
... The number below it isn't significant, as long as it makes sense.
... additional is the same as other.

Bruce: Not quite the same but still not good.

awk: we should make a decision on the one item (seizures change).

jf: specific concerns. going to share an email...

<JF> The conformance model for WCAG 2.1 uses the WCAG 2.1 A / AA / AAA model, and success criteria are additive. No features from WCAG 2.0 were changed, even for optimization, nor renumbered, even to ease presentation, in order to make it clear that WCAG 2.0 requirements are fully backwards compatible.

<Zakim> JF, you wanted to look at the backwards compatibility requirements

glenda: changes to 2.0 are not in scope.

katie: what about 2.6?

awk: We could potentially consider these changes. This change is a straight forward change and would not impact backward compatability.

jf: I could roll with clarifying "seizures".

bruce: You are ok with us adding a new guideline under a principal. I don't feel like that's any more substantive than adding two words.

<AWK> Proposed change - adding "and physical reactions" and corresponding change to the GL text language "or physical reactions" and adding 2.2.7 Animation from Interactions to GL 2.3

Josh: The change to 2.3 seems a bigger change.

RESOLUTION: add "and physical reactions" and corresponding change to the GL text language "or physical reactions" and adding 2.2.7 Animation from Interactions to GL 2.3 providing this does not contravene CR.

<AllanJ> scribe: allanj

awk: changing things are complicated. not seeing any consensus. so tabling the discussion of changing 2.6.x
... making more progress on implementation when we are together.

renaming 2.6

khs: current - Additional Sensory Inputs
... suggest Non-keyboard/pointer Modalities
... or change 2.5 to Non-Keyboard Accessible and include 2.5 and 2.6 stuff
... Other Modalities as a rename just doesn't work
... heading should identify what it is. Has issue with "other" or "additional"

mj: Accessible Operation.

awk: seems a rewording of Operable
... Non-keyboard accessible make me uncomfortable

** 5 min alarm goes off....

awk: on to implementations
... scorecard still lagging behind

https://www.w3.org/WAI/GL/WCAG21/CR/scorecard

https://www.w3.org/WAI/GL/WCAG21/CR/implementations

Lego implementation - target size

mj: home page works fine. the rest of the site falls apart. is it valid to take just the home page (tiny slice - the url never changes for the entire site)
... hard to find a site that all items on a site pass.
... most fail on social media icons

gs: target size is AAA

mj: can we use one page?

awk: yes. doesn't have to be entire site

jake: need to have an interative process. why doesn't it exist

awk: if we were doing this over, would define what is needed to get to the editors draft you would need - understanding, implementations, techniques, etc.
... until all of those things exist the item would not make it into the draft.
... where we are as to what is needed
... reviewing implementations https://www.w3.org/WAI/GL/WCAG21/CR/implementations
... need 1 more AAA and 3 more AA entire sites in next 2 weeks
... if all sites pass. need a bunch more AA sites (5-10 pages).
... find some sites

dm: can we do test product sites.

mc: must be available thru CR phase.

jw: if site is known 2.0 conformant, do you need to check again to add 2.1 SC.

awk: would need to have a reliable conformance report.

mc: need to have many more sites that are conformant to test.

jw: 2.1 conformance will not be met by accident

mc: we will need to work with site to get them up to speed.

awk: implementation tasks - anything particularly hard.
... need more information about failures.

mc: could add a failures column.

awk: see 1.4.13 click on 4, but you see 5 items. filter out non priority items.
... need implementations for Target Size, pointer cancelation, motion activation (facebook picture panorama??)
... many CFCs coming

- DRAFT -

Accessibility Guidelines Working Group Teleconference

20 Mar 2018

Attendees

Contents

Work on open issues

808

807

805

763

778

763

Non-text contrast

Issue 772

803

806

renaming 2.6

Lego implementation - target size

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output