W3C

- DRAFT -

Accessibility Guidelines Working Group Teleconference

18 Jul 2017

See also: IRC log

Attendees

Present
AWK, KimD, JakeAbma, Laura, ChrisLoiselle, JF, steverep, jasonjgw, MikeGower, Greg_Lowney, Melanie_Philipp, Makoto, dboudreau, Detlev, wayne, WayneDick, chriscm, lisa, bruce_bailey, MichaelC, Rachael, kirkwood, marcjohlic, Pietro, jon_avila, alastairc, JMcSorley
Regrets
Mike_Elledge, EA_Draffan, Kathy_Wahlbin
Chair
AWK
Scribe
ChrisLoiselle, AWK

Contents


<AWK> +AWK

<WayneDick> Did the password change?

<ChrisLoiselle> scribe: ChrisLoiselle

<lisa> i am getting tht this meeiting is canceled

<lisa> thanks

Personalisation: https://github.com/w3c/wcag21/issues/6

<lisa> looking better

Adapting Text: https://www.w3.org/2002/09/wbs/35422/AdaptingTextJuly6/results

<laura> The current language in the full draft guideline is at:

<AWK> https://rawgit.com/w3c/wcag21/adapting-text_ISSUE-74-78-79/guidelines/#adapting-text

<laura> https://rawgit.com/w3c/wcag21/adapting-text_ISSUE-74-78-79/guidelines/#adapting-text

<laura> +q

AWK: Survey has old text, apologies. Correct version is always version in github

I can hear you.

<KimD> *fine for me

<Detlev> voice fine for me (DE)

<Alex_> sounds ok to me

AWK, to Laura: Summarize changes.

<laura> https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/thread.html#msg61

<laura> https://github.com/w3c/wcag21/pull/303/commits/026d2537294187d1357c7a6ace0037f683d228f8

JF: comfortable with this. In documentation, like more explanation on font size, for less engaged clientele. Ems is a width measurement

<lisa> +1 from me

Laura: Agrees we need to explain in understanding

<steverep> em is not a width measurement

Wayne: Agrees with John F.

<lisa> Just want to say thanks to Laura for all this work

<bruce_bailey> * I had great difficulty w/ webex this time, had to dial in.

Wayne: Terminology needs to be explained. Language seems correct, however we need to make sure techniques and understanding needs to be clear.

<lisa> (and eveyone else involved)

<Zakim> AWK, you wanted to ask why "underneath paragraphs" instead of "between paragraphs"?

Laura: It is easier to test "the bottom" i.e. underneath, unless it is hard to test. Steve, can you confirm?

Steve: If you specify between, ambiguity arises. It is not a within element measurement.

Alex: Asking clarity on style property definition.

Laura: Taken from UAG. We will publish definitions in next round...
... I have pull requests for both

<laura> https://github.com/w3c/wcag21/pull/303/commits/026d2537294187d1357c7a6ace0037f683d228f8

<laura> https://github.com/lauracarlson/wcag21/pull/1/commits/a74ea8bcec7098f22c115b7a7e0bd3659aa0d890

AWK: All you need to do is go into index file and uncomment. AWK to see if he can do that to edit...

Wayne: Do we consider headings to be paragraphs?

JF: They are block level elements, but aren't considered paragraphs.

Steve: Have to rely on people using <p> element for paragraphs. Headings is another issue, but it is not testing what you need to do. Same thing can be said for tables, embedded lists. Scope needs to be present to be testeable

<lisa> we wanted to have sections in as wele, but we backed down on that for testability - same issue

Jake: Regarding "underneath"...is it the same zoom? Is different wording needed?

Laura: That has not be brought up, it is a good question.

<lisa> not an issue for left to right

Jake: We need to look at this from all languages

Steve: defers to Wayne.

<lisa> wording is fine for hebrew

<steverep> Ah I remember...

Wayne: In top to bottom languages, letter spacing has different significance. It would need to be a technique level thing where we specify. I don't see an issue, we have looked at it.

AWK: We can ask for input from internationalization group.

Alex: I want to confirm on testing. On WCAG 2.0, we test SC. We don't try to overlap. It seems that this SC compounds scrolling. Is it common understanding that we are not expecting people to test SC simultaneously
... Makes it harder to meet SC if we are creating SC that compounds together and resulting compliance.

<Pietro> I'm connected only by IRC because of I'm travelling by train

<JF> +1 to Mike

MikeGower: For 1.4.12, we'd note all tests in one place. We wouldn't compound other SC.

Alex: Are we combining multiple SC to meet testing requirements? I.e. its proper to test SC individually of each SC

<laura> Draft Technique: https://www.w3.org/WAI/GL/wiki/Allowing_for_Spacing_Override

JF: Page has to usable at end of day, that needs to be considered.

<lisa> +1 to diffrent discussion

<AWK> @@@ issue - do we test SC individually or in combination? Do SC like this compound testing challenges?

Alex: We need to look at testing SC to SC vs. SC + SC to test appropriately and whether or not this causes issues.

<laura> +1 to diffrent discussion

<gowerm> +1 to look at after August

<lisa> Can we get back to sc for before august?

JF: There are instances where testing for one might show you that you broke another SC.

<laura> Think we are off track for this agenda topic.

Alex: Regarding Spacing and SC, looking at SC independently they pass. I've never seen a test or a technique to meet multiple SC simultaneously.

<Zakim> Greg, you wanted to say disagree with the contention that saying "paragraphs" limits testing to blocks marked up with P elements. As the spec is technology independent, we cannot

AWK: Let's view the Queue.

<Greg> I’m concerned about the assumtion that saying "paragraphs" limits testing to blocks marked up with P elements. As the spec is technology independent, we cannot rely on the author marking up "paragraphs" as such, or even being able to, nor should we allow a loophole where the author can avoid this SC by using DIV instead of P. If you want to say that it applies only to something programmatically

<Greg> de

<Greg> terminable to be a paragraph, we could say that, but I don’t think it’s implied. I would lean towards referring to block level elements, although I’m not entirely sure how that term would apply to other technologies.

<lisa> i think it is a technolgy agnostic thing , techniques are diffrent

Greg: Loophole of using divs rather than p's . Perhaps change to block level elements , which makes it broader.

Laura: It would be harder to test.

<AWK> @@@ issue - should we reference block-level elements instead of just paragraphs?

<gowerm> +1 to Steve. This is just testing malleability

Steve: your volume is low, would you mind putting your thought in IRC? Sorry.

<lisa> agree with greg

<lisa> that it is agnostic

<Greg> I actually would expect that a lot of users would add space to block level elements rather than P, so we'd help them more if we tested that configuration.

<lisa> but worth putting it in

<laura> block-level elements instead of just paragraphs would be a nightmare to test.

Style definition, I thought we were going to drop it for adapting. We could substitute the word "change" and it is the same SC

<alastairc> This SC applies to all text on the page, so adding padding to block level elements (including layout) would again blow-apart most websites.

<AWK> @@@ do we need the adapted def?

<KimD> +1 to "change" replacing "adapt"

<laura> +q

<Greg> My concern with the word adapt does not apply to this draft; it was about the earlier wording where it was broad enough to include adaptation at the server level.

<AWK> adapted definition: https://rawgit.com/w3c/wcag21/adapting-text_ISSUE-74-78-79/guidelines/terms/21/adapted.html

Detlev: One issue on paragraph. In fictional text, typography might change.

<AWK> style properties def: https://rawgit.com/w3c/wcag21/adapting-text_ISSUE-74-78-79/guidelines/terms/21/style-properties.html

Lisa: Learning increases if breaks are expected or available. Spacing between paragraphs should be able to override it. A mechanism could be available.

Detlev: Different lines in a dialog , there should be sufficient lines, which would be closer to each other, vs. narration which would be having a larger spacing between the text

<alastairc> in HTML / ePub, you can't stop people from overriding the margins, that isn't the issue.

<laura> SC text starts: If the technologies being used allow the user agent to adapt style properties of text, then no loss of essential content or functionality occurs by adapting all of the following:

Wayne: The helpful semantic device is a harmful device. We want the ability to change that.

<AWK> People should think about whether we need to continue to discuss this today and put off other items, pass it and allow public comment, or stop now and take it up on Thursday.

Laura: Person needs to be able to read it. The ability to override what the author provides.

<gowerm> public comment +1

<lisa> i think it is ready to go

<JF> +1 to "let's put this out as it is now"

<laura> +1 for pubilc comment

<alastairc> +1 to "let's put this out as it is now"

<allanj> +1 public comment

<Makoto> +1 for public comment

<WayneDick> Put it out

<steverep> +1 please please put this through

<bruce_bailey> +1 for public comment

<Detlev> fine for public comment

<jon_avila> public comment now

<JakeAbma> +1 for public comment

<chriscm> +1

+1

<Pietro> +1

<kirkwood_> +1

<Rachael> +1

RESOLUTION: Accept to editor's draft. CFC to follow

<WayneDick> +1

thanks: )"

<david-macdonald> I'm in queue to support public comment now... Regarding Alex's concern of interoperability of all the new SCs, I think we need to see what's going to be in the 2.1 and then do an interoperability pass after August, and either drop of change conflicts at that point.

s/ RESOLUTION: Accepting current github version of SC.

<gowerm> And my point was going to be that the wording on paragraph is to test for an ability to control block-level spacing. If it passes paragraph, it should allow for malleable block spacing on other elements.

<laura> Deep thanks to everyone.

s/ RESOLUTION: Accepting current github version of SC.

Conformance changes: https://www.w3.org/2002/09/wbs/35422/62-63-71-conformance/results

<gowerm> +1 to Bruce's edit suggestion

Bruce: I believe my note addresses James' concern. I.e. if the note is changed.

AWK: There are already two notes, I don't believe they are reflected in rawgit

<Detlev> AWK: link above doesn't work (for me) - not because of " at the end

<bruce_bailey> Here is the note w/ my suggested edit:

<bruce_bailey> A full page includes versions of the page that are automatically generated by the page for various screen sizes. Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform.

Makoto: Is testing with various screen sizes necessary?

<alastairc> If they don't have variations, what's the problem?

AWK: Are we talking about developing a webpage that has different breakpoints, in an university setting?

<chriscm> Delta flights have websites hosted locally on flights that allow access to movie content on your tablets or screens on the backs of chairs.

JF: Delivery company , where you sign the document on a tablet, is web based...delivery person's tablet is where you'd interact with the content , exclusively for a particular form factor

Makoto: Agrees with JF's example

<kirkwood_> would kiosks be an issue?

Alastair: If they don't have the variations, what is the problem?

<bruce_bailey> I think internal-only pages where the screen size is known and fixed meets the CR.

<alastairc> Perhaps start the note: "If a full page includes variations of the page that are automatically..."

JF: Accessibility Supported , where you can't reflow text, form factor doesn't allow it. Application is meant to be run on a closed environment.

<bruce_bailey> The understanding document could also talk about intranet vs Internet.

JF: We should address the issue. Makoto identified a potential gap.

<AWK> @@@ Issue - what about a page that is viewed in a closed environment, etc.

<alastairc> Perhaps start the note: "If a full page includes variations of the page that are automatically..."

Thanks, Alastair

<Zakim> gowerm, you wanted to discuss "generated by the page"

MikeG: Isn't this addressed by the wording generated by the page?

David: Trying to plug issue of breakpoints

<gowerm> "generated by the page" covers authoring that introduces breakpoints

<MichaelC> s|s/ RESOLUTION: Accept to editor's draft. CFC to follow s/ RESOLUTION: Accepting current github version of SC.||

AWK: Do we have to test all the breakpoints if we aren't using them?

David: Introduction of language for specific use cases can be introduced if necessary.

<WayneDick> +1 to next draft

Would like to open to public comment

<alastairc> +1 to Bruce's comments, then pub draft.

David: had a twitter poll in regard to the issue, wants to formalize the issue.

JF: The understanding language would need to be looked at. Where the use scenario can be addressed.

<lisa> +1 to i cant find the text we are agreeing on

Makoto: Accepts the direction we have been talking about. Add this note to the conformance section. Open issue to explain text in understanding.

<KimD> *Lisa, look at https://rawgit.com/w3c/wcag21/62-63-71-conformance-changes/guidelines/#conformance-reqs

<AWK> https://rawgit.com/w3c/wcag21/62-63-71-conformance-changes/guidelines/#conformance-reqs

Lisa: Question on old vs. new text.

AWK: Look for the green note.

Lisa: Asks about Browser extensions.

<laura> The text is…“Note: A full page includes each variation of the page that is automatically generated by the page for various screen sizes. Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform.”

David: That is a different issue. Lisa states "Ok".

<alastairc> Suggest: "If a page includes variations that are automatically generated by the page for various screen sizes, then each variation needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform."

<bruce_bailey> A full page includes versions of the page that are automatically generated by the page for various screen sizes. Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform.

<chriscm> @alastairc: Why is the "automatically" distinction required?

<jon_avila> recommend not use the word "Version" as that could imply a separate page

Wayne: Makoto's use case would be excluded as it doesn't meet the "if" clause

<AWK> A full page includes alternate rendered variations of the page that are automatically generated for various screen sizes. Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform.

<lisa> time reminder

<alastairc> @chriscm: well, partly because it was in there to start with, and I guess to imply that it is the site creating the variations, rather than by user-override.

<chriscm> @alastairc: Does that suggest that specifically designed variations would not apply for some reason?

<steverep> How about talking about user agent dependence? "If a page's content depends on the user agent, then each possible delivery must conform."

AWK: Editorial recommendations are taking place. Are there objections? Should we send this to CFC for Andrew's version at 12:02 and information related to understanding

<WayneDick> +1 to inclusion granting discresion to editors

<dboudreau> +1 as well

<JF> +1

<laura> +1

<JakeAbma> +1

<alastairc> @chriscm: no, but I think that they would be considered separate pages?

<alastairc> +1

<Makoto> +1

<jon_avila> +1 although I think we may need to expand past screen size in case their are other variations for other factors

RESOLUTION: Accept version posted by AWK at 12:02. Also create an issue for clarifications to be made in understanding document.

<chriscm> @alastairc: Hmm, interesting. I agree... is there a clarification doc on this?

Personalization: https://www.w3.org/2002/09/wbs/35422/suuortPersonalization/results

<alastairc> @chriscm: I don't think so, we've all been running under the assumption that everything applies!

<chriscm> @alastairc: Do you agree that this is confusing? What is the best way to clarify? Or is this just me being overly development minded...

<lisa> https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/0196.html

AWK: Changes in techniques and understanding. There would be a piece for supplementary documentation. COGA is interested in something be introduced as AA vs. AAA

<bruce_bailey> Can someone post the coga listserv URL?

<AWK> https://lists.w3.org/Archives/Public/public-cognitive-a11y-tf/2017Jul/0023.html

JF: The key to transformation , i.e. text links to iconography, we need a fixed taxonomy. The lookup list needs to address internationalization as well.

<chriscm> @alastairc: absolutely.

<KimD> *sorry, is this the current and correct language? https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-6/guidelines/sc/21/support-personalization-minimum.html

<lisa> look at the email https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/0196.html

JF: Look at two SC. One at AA and one at AAA. Which would use User Agent tools. We need to need is loose enough to use schema.org etc. for fixed taxonomy .

<AWK> Current version: https://rawgit.com/w3c/wcag21/personalization-metadata_ISSUE-6/guidelines/#personalization-metadata

AA won't reference Metadata. AAA would reference metadata.

<lisa> i hope not

<lisa> i did not agree to this

Fixed number of controls. Create a list of navigational buttons. Provide supplemental info on those controls, at AA level, you'd meet that requirement of explaining to the user.

<AWK> Lisa, no one has agreed to anything, john is making a suggestion

<lisa> this is a new proposal that has not been discjussed

Same for multi-part forms, page 2 of 5...can be provided as prose info.

<lisa> ok, i though he siad we are on the same page

<chriscm> lisa: it is being discussed right now...

AAA is where we'd add metadata

<lisa> https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/0196.html

Lisa: I do agree with limited scope at AA. And something specific at AAA. I think what we have to do now is have another call without COGA. Single A wording needs to be entered.

We need to speak to people with issues.

AWK: I don't think the absence of comments and objections should be looked at yet due to when the questionairre went out and time to respond.

<david-macdonald> 3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A) ...may cover part of it and could be combined after august

<lisa> not asking you to mike, we are asking if there is any way forward

AWK: I have concerns at AA. We don't have much time to discuss details. We need to understand how we need to properly scope this. AAA may be better option.

<lisa> thanks john

<Zakim> bruce_bailey, you wanted to offer clarification for what it means in 2.0 for an SC to apply to all content

<bruce_bailey> http://www.w3.org/WAI/GL/wiki/Talk:WCAG_2.1_Success_Criteria

Bruce: AA vs. AAA , we know AAA where the SC is not supported by Technology. I.e. spreadsheets and presentations. Not appropriate for AA: Bruce to paste in URL

Wayne: If we get this to one testable issue, we should have a AA criteria. Personalization works for people with low vision disabilities.

<bruce_bailey> from: https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-levels-head

<Zakim> MichaelC, you wanted to ask about priorities for remaining time

<bruce_bailey> whether it is possible to satisfy the Success Criterion for all Web sites and types of content that the Success Criteria would apply to (e.g., different topics, types of content, types of Web technology)

<bruce_bailey> My point is that personalization is not possible to satisfy the SC for all web site and types of content

MichaelC: Would love to see Personalization at AA. I don't have a wording that will get it in at AA. AAA seems more appropriate. Strategically, what is most important? If we attempt at AAA it may get in vs. trying at AA.

AWK: If we receive public comments that this should be moved to AA, that may be worthwhile after the August date.

<alastairc> @bruce_bailey I think it can, with a closed taxonomy.

<Zakim> JF, you wanted to say I am in favor of trying for a AA SC as well as the AAA, and offer to help get there

<chriscm> +1 Lisa was next!

Lisa: If we get a sub-group to look at it, I don't think we should waste call time. MikeGower, JF, etc. may want to address this off the phone.

JF: I agree with Lisa and will help. We do have tools (native semantics in HTML) or ARIA (i.e. landmarks).

example: iFrames have titles, then AAA gets really granular for modification of page.

<lisa> the term we are using is context

Jason: Clarity on defining function of controls. Taxonomy would be needed to be used. Accessibility Supported taxonomy use taxonomy once available.

<lisa> who could join us in a call to recraft the language

<Zakim> alastairc, you wanted to ask about John's point on metadata vs 4.1.2

<alastairc> For navigation, form elements and interactive controls _conventional_elements_ can be programmatically determined.

<Detlev> +1 to "conventional elements" instead of context

<lisa> lovely

<AWK> Scribe: AWK

<ChrisLoiselle> Alastair: Question to JF: Struggling to see how to referenced shared vocabulary ? How to reference an external spec? Schema.org, COGA, taxonomies, etc.

<lisa> some techneques are in the issue in github

JF: The way I'm thinking about it is that AAA is a fixed taxonomy

<lisa> inculding scema.org

JF: and at the AA there is some sort of programmatic determination

<lisa> john can the proce use a controled vocablery?

<lisa> prose

JF: I keep thinking about the title attribute being spec'd to provide additional information
... left open into prose rather than requiring a specific taxa

AC: Fixed list is most useful

JF: agreed, but we don't have the robust ecosystem available at this time

<chriscm> @JF: I'm hungry... come on man! :P

<gowerm> JF: The COGA spec may be ideal for COGA, but remember that we're discussing personalization here. There are a lot of other personalization considerations beyond COGA.

Chris: thinking about the AA req, not entirely opposed but need to see the wording
... do feel strongly that leaving a AAA req that says what is needed should be done with or without the AA SC
... that will bring about more discussion and development

<JF> @MIkeG - no disagreement here, which is why I want to leave it as "fixed taxonomy" as opposed to "Coga Semantics"

<JF> +1 - do both

<Zakim> MichaelC_temp, you wanted to say every week now is 20% of the remaining SC processing time; better to accept AAA version now, work on other SC, and look further during the

<KimD> *I would have far fewer concerns at AAA

<gowerm> I do not have cycles to do it this week.

<chriscm> Add me pls.

<kirkwood_> please add me

<lisa> please send me your email

<chriscm> @lisa: chris.mcmeeking@deque.com

<bruce_bailey> Per Understanding, at AA, any SC should apply to “all types of Web technology”.

<david-macdonald> {Present+ David-macdonald

trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. Accept to editor's draft. CFC to follow
  2. Accept version posted by AWK at 12:02. Also create an issue for clarifications to be made in understanding document.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/07/18 16:40:37 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

WARNING: Bad s/// command: s/ RESOLUTION: Accepting current github version of SC.
FAILED: s/ RESOLUTION: Accept to editor's draft. CFC to follow s/ RESOLUTION: Accepting current github version of SC./
Succeeded: s/RESOLUTION: Accept to editor's draft. CFC to follow/RESOLUTION: Accepting current github version of SC./
Succeeded: s|s/ RESOLUTION: Accepting current github version of SC.||
FAILED: s|s/ RESOLUTION: Accept to editor's draft. CFC to follow s/ RESOLUTION: Accepting current github version of SC.||
Succeeded: s/With clarifications/Also create an issue for clarifications to be/
Default Present: AWK, KimD, JakeAbma, Laura, ChrisLoiselle, JF, steverep, jasonjgw, MikeGower, Greg_Lowney, Melanie_Philipp, Makoto, dboudreau, Detlev, wayne, WayneDick, chriscm, lisa, bruce_bailey, MichaelC, Rachael, kirkwood, marcjohlic, Pietro, jon_avila, alastairc, JMcSorley

WARNING: Replacing previous Present list. (Old list: AWK, ChrisLoiselle, JF, KimD, lisa, MichaelC, chriscm, alastairc, Greg_Lowney, Detlev, Pietro, MikeG, David-MacDonald, jasonjgw)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AWK


WARNING: Replacing previous Present list. (Old list: AWK, David-MacDonald, KimD, JakeAbma, Laura, ChrisLoiselle, JF, steverep, jasonjgw)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AWK, KimD, JakeAbma, Laura, ChrisLoiselle, JF, steverep, jasonjgw

Present: AWK KimD JakeAbma Laura ChrisLoiselle JF steverep jasonjgw MikeGower Greg_Lowney Melanie_Philipp Makoto dboudreau Detlev wayne WayneDick chriscm lisa bruce_bailey MichaelC Rachael kirkwood marcjohlic Pietro jon_avila alastairc JMcSorley
Regrets: Mike_Elledge EA_Draffan Kathy_Wahlbin
Found Scribe: ChrisLoiselle
Inferring ScribeNick: ChrisLoiselle
Found Scribe: AWK
Inferring ScribeNick: AWK
Scribes: ChrisLoiselle, AWK
ScribeNicks: ChrisLoiselle, AWK
Found Date: 18 Jul 2017
Guessing minutes URL: http://www.w3.org/2017/07/18-ag-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]