W3C

- DRAFT -

Accessibility Guidelines Working Group Teleconference

11 Sep 2018

Attendees

Present
(no, one), alastairc, bruce_bailey, JakeAbma, Katie_Haritos-Shea, MichaelC, Glenda, marcjohlic, david-macdonald, kirkwood, jon_avila
Regrets
Brooks, KathyW, Chuck, JimA, Mike_Elledge, Laura, Detlev, EA_Draffan
Chair
AWK
Scribe
Glenda

Contents


<AWK> +AWK

<AWK> Scribe:Glenda

Feedback requested re COGA documents: https://www.w3.org/2002/09/wbs/35422/coga-usable-separate/

AWK: Encourage everyone to review this survey. Proposing splitting a long COGA Document into two documents. COGA task force would like to publish this promptly. So please read and review and comment.

agendum 1. "Feedback requested re COGA documents: https://www.w3.org/2002/09/wbs/35422/coga-usable-separate/" taken up [from AWK]

Alastair: Gap Analysis has an primary audience of people creating specifications. The “Making content usable for people with cognitive and learning disabilities” is designed for Web developers and content creators (mainly interested in the user needs, user-testing, user profiles).

<JF> +1 on clarity: are we agreeing with the "process" or the "content"?

Marc: is the question primarily about “seperating the documents” or are we also review content in detail?

Katie: I think the intent is to break it into two documents…and also do an initial review of the content.

Alastair: Theoretically, we have all looked at the Gap Analysis before. The “Make Usable” part is new and is worth review.

David: Confused about the Gap Analysis being something that would be used to create a standard.

Alastair: Helps people who want to create a standard because they understand what gaps exist. This is not a requirement document. This Gap Analysis is not aimed at the broad audience of web designs and developers.

AWK: we are looking for both the concept (of breaking it into two pieces) and the content review. This is still at a working draft stage. So please do review the content, especially of this new part for Making Content Usable https://rawgit.com/w3c/coga/separate-usable-doc/content-usable/usable.html

Marc - this survey is both “should it be split” AND give feedback on content.

Review of open issues

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

AWK: are there techniques or understanding documents that anyone wants to promote here (as needing review) so we can move them forward?

<AWK> https://github.com/w3c/wcag/pulls?q=is%3Apr+is%3Aopen+label%3A%22Ready+for+initial+review%22

AWK: this link shows the items available for initial review.

<alastairc> Jake's one is almost there, but a couple of known edits to do.

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

AWK: Techniques for WCAG 2.1 does not itself follow G141 - https://github.com/w3c/wcag/issues/470

<alastairc> The headings for this page https://www.w3.org/WAI/WCAG21/Techniques/

<alastairc> I think they want the top-level of list items to be headings instead of list items

AWK: there are headings.

Michael: agreed

Alastair: I think they want things like “ARIA Techniques” and “Client-Side Script Techniques” and “CSS Techniques” as headings.

Michael: this is not a violation, because it is using a list

David: I suggest we use headings, I think more people would like it better.

Michael: That would be contrary to W3C style for table of contents. But we are not bound to that.

AWK: anyone on the call that would fail this page?

David: No. I would call it a best practice (and suggest headings). You could use headings inside a list.

<alastairc> I wouldn't fail it, but would suggest they use headings for the top-level items (instead of nested lists).

Glenda: I would not fail it…because it has proper semantics.

AWK: it would be valuable to add an ID to each of these top level bullets, so you could link directly to one of these major sections.
... I propose we respond back. “Thank you for your response. We disagree that this page fails G141. We agree it is desirable to have a link to each of these sections to make it possible to link directly to these sections. So we will be adding the ability to link to the sections.

<Zakim> bruce_bailey, you wanted to ask about SR use

Bruce: can a screen reader user navigate the list as easily as they could headings?

<alastairc> I'd go with heading by preference, so h3s then non-nested list.

David: confirmed you can navigate nested lists as needed.

AWK: who prefers headings?

<bruce_bailey> +1 to heading

<david-macdonald> +1 headings

<alastairc> +1 headings

<JF> +1 to headings

<marcjohlic> +1 to headings

<JakeAbma> +1

<kirkwood> +1 to headings

<AWK> +1

AWK: decision - switching you headings (with ID) so they can be targeted in a link

<AWK> "Thank you for your response. The Working Group discussed this and disagree that the Techniques index page fails to meet the G141 technique. However, the group does agree that it is important to be able to link to the specific sections, and does recognize the usability benefits of using headings, so will make the change requested."

<marcjohlic> +1

<kirkwood> +1

+1

Next one 469 - Contrast ratio for text that is part of inactive UI component - https://github.com/w3c/wcag/issues/469

“Incidental: Text or images of text that are part of an inactive user interface component, “

They are incorrect. Direct quote from normative (above)

<jon_avila> +1 to David -- it is a gap -- but this is what the standard is

<alastairc> Previous answer: https://github.com/w3c/wcag21/issues/805

David: We should let them know that we understand there is a gap, and that this will be reviewed in future versions of AG in relation to the needs of low vision preferences.

<AWK> "Thank you for the comment - the WCAG 2.1 specification does not require a minimum contrast ratio for inactive elements ("Incidental: Text or images of text that are part of an inactive user interface component"). Having a higher contrast level for text of this sort can be regarded as a best practice even though it isn't required."

Marc: Would it help to also point them to the Non-text contrast understanding document?

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

Glenda: I’d just focus on the Text Contrast requirement.

<kirkwood> personalization

<AWK> This is a gap that may be able to be addressed in future versions through personalization.

Glenda +1

<kirkwood> +1

<marcjohlic> +1

<bruce_bailey> +1

<JakeAbma> +1

AWK: Next one: Technique SCR29 needs updating https://github.com/w3c/wcag/issues/468

<jon_avila> Examples should do things correctly though and it should be easy to add

<JF> +1 to Jon

+1 to Jon

AWK: anyone want to volunteer to fix it? so we can have an answer to this question?

Jon: add role of button and possible list for space bar and enter

AWK: Jon, you can just do it in an email to Alastair and AWK…and we can add it in github.

<alastairc> I think this is the '2.1' verison: https://www.w3.org/WAI/WCAG21/Techniques/client-side-script/SCR29

<AWK> https://www.w3.org/WAI/WCAG20/Techniques/working-examples/SCR29/action-on-div.html

AWK: 465 Understanding 4.1.3 - wrong id reference in anchors https://github.com/w3c/wcag/issues/465 I think this goes directly to Michael.

Assigning to Michael and AWK

464 and 460 are editorial, we will handle those.

errata? 1.4.11 does not exempt logos, like 1.4.3 exempts logotypes - https://github.com/w3c/wcag/issues/447

AWK: alastiar you wrote back over a month ago. let’s finalize that response. Would anyone respond differently?
... Our interpretation that most orgs require the color of the brand as essential, logos are exempt due to essential.

Glenda agrees with AWK and Alastiar

AWK: assigning to Alastair to respond
... Next 445 Reflow understanding - Video size & location https://github.com/w3c/wcag/issues/445
... is this editorial?
... just some mechanics that need to be worked out here.
... Minor link errors in Understanding 1.4.12 Text spacing https://github.com/w3c/wcag/issues
... Editorial - Understanding 1.3.5 - relative link in the SC boxout at the top isn't working - https://github.com/w3c/wcag/issues/442
... Failure technique F87 contradicts the Accessible name and desc algorithm https://github.com/w3c/wcag/issues/433

<MichaelC> ant clean

<david-macdonald> http://davidmacd.com/blog/inserting-content-with-css-accessibility.html

Alastiar: It is basically still a valid failure. Need to tweek the procedure.

<alastairc> From the desc: "For users who need to customize or turn off style information in order to view content according to their needs, assistive technologies may not be able to access the information that is inserted using CSS. Therefore, it is a failure to use these properties to insert non-decorative content."

Jon: for low vision users who need to use their own style sheet, that psuedo content is lost. So it would fail Accessibility Supported. This is not a screen reader issue. It is a low vision issue.

s /Alastair/Alastair

<JF> +1 to JOn

jon: and you can’t search on psuedo content and you can’t select it. Just becasue CSS folks say it is great, doesn’t mean it is accessible to people with disabilities. People with low vision or coga disabilities may need to use a “find” on page..and this content would not be available to them.

Glenda: +1 to Jon

David: agree

<alastairc> PR for the change that would be needed: https://github.com/w3c/wcag/pull/473/files?utf8=%E2%9C%93&diff=split

AWK: I agree, but playing devil’s advocate, the WG would say that is not limited to people with disabilities, that effects all users (like images in text).
... we need to respond back to this one Does anyone want to write up this proposed response? Then we can review that proposed response.

Alastair volunteers

What about https://www.w3.org/TR/WCAG20-TECHS/F3.html F3: Failure of Success Criterion 1.1.1 due to using CSS to include images that convey important information

isn’t css by definition “presentation”? 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

SC 1.3.5 is not restricted to markup languages but SC 1.3.6 is 425 https://github.com/w3c/wcag/issues/425

AWK will take a look at this one

This is editorial https://github.com/w3c/wcag/issues/423 Enabling code-examples to reflow

AWK: Need to add HTML Landmark techniques https://github.com/w3c/wcag/issues/422

<AWK> AWK will add these to the list

421 2.2.6: Timeouts - reference to compliance https://github.com/w3c/wcag/issues/421

AWK: we just need to ping Thaddeus. AWK did it.
... 416 Understanding Success Criterion 1.3.4: Orientation https://github.com/w3c/wcag/issues/416
... we will put it to the list to see who will volunteer to handle this one.

AOB

AWK: Other Business: Michael, Alastair and I have been compiling all the items related to the process review. We are meeting again this Friday. We will be coming up with the agenda for TPAC. You will have an opportunity to make suggestions. comments.

<AWK> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/09/11 16:29:16 $

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)

Succeeded: s/Alastiar/Alastair/
Default Present: AWK, alastairc, bruce_bailey, JakeAbma, Katie_Haritos-Shea, MichaelC, Glenda, marcjohlic, david-macdonald, kirkwood, jon_avila
Present: (no one) alastairc bruce_bailey JakeAbma Katie_Haritos-Shea MichaelC Glenda marcjohlic david-macdonald kirkwood jon_avila
Regrets: Brooks KathyW Chuck JimA Mike_Elledge Laura Detlev EA_Draffan
Found Scribe: Glenda
Inferring ScribeNick: Glenda
Found Date: 11 Sep 2018
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.)


[End of scribe.perl diagnostic output]