Accessibility Guidelines Working Group Teleconference

29 Oct 2019


AWK, Jared_Batterman, MichaelC, Raf, Jennie, bruce_bailey, Wilco, Rachael, jeanne, mbgower, alastairc, maryjom, david-macdonald, JF, Katie_Haritos-Shea, Laura
Justine, Chuck, Detlev
Rachael, Wilco


<AWK> New member Jared Batterman, for Mitre

<Jared_Batterman> Thanks!

<Rachael> Scribe: Rachael

Charter update

AWK: For our charter, there were a bunch of comments and a few formal objections. We've been working with those organizations to address those.
... If the charter is delayed, we can't publish the first public working drafts until the charter is approved

<jeanne> +1 to wilco's concern

<jeanne> We want to at least include mobile apps

<alastairc> silver scope

<david-macdonald> "without writing normative requirements for content not at a url in non-web platforms.

<Zakim> jeanne, you wanted to ask about mo bile apps

<bruce_bailey> +1 to including mobile apps

<bruce_bailey> ack awk\

<Zakim> AWK, you wanted to ask if Michael means native mobile apps or hybrid?

<Zakim> bruce_bailey, you wanted to ask about “Official” version moniker on new docs

<bruce_bailey> https://www.w3.org/WAI/WCAG21/Understanding/

Silver – FPWD expectations

AWK: When the charter is completed and we can publish first public working drafts we will create editors drafts.
... this will come up quickly. We have a limited number of meetings before the end of the year, so when the silver taskforce says they are ready to put out at FPWD it will not include everything we might dream.
... it will certainly not include everything later working drafts will. We want to hear from Silver what they expect will be in it to set expectations.

Jeanne: We are still working out what is ready enough to go into the working draft. We will have the structure of silver. We will have the higher level principles of what we plan to do for conformance to show what direction we are going.
... we hope to have 3 guidelines included to illustrate the direction we are going. 1 will be a new guideline that is not in WCAG.
... what we will have for test will just be a description of the test and method because we are still working on the process of how to write tests. We don't have anything to send to Wilco and the ACT group. We are trying to get examples ready for ACT to help us with.
... I think the testing will be the weakest part. We will have some guidelines that will show more of the plain language aspect of how to include the silver guidance.

AWK: I think the FPWD, the goal is to get public feedback. It may be possible that for a topic like conformance, we can say that we narrowed our conversation to these two models or here is what we are currently considering but we are grappling with these concerns that have been raised.
... There are various ways topics can be included that are not final in order to seek directional guidance.

<Zakim> Wilco, you wanted to ask how much conformance work is in FPWD

Wilco: How much conformance will be in the FPWD

Jeanne: Not a lot. We have the general architecture. We have not solved the major large issues that would allow us to say that these are the different models, which do you think are the best.
... we can't drill to the point system yet.

Wilco: Will there be editors notes to point that out?

Jeanne: Yes, a ton.

AWK: Any other questions or anything else to add?

Jeanne: We are also working on an explainer to go with the FPWD. That is where we hope to address many of the questions.

MichaelC: Bruce was asking about timeline and I think that relates to completeness. Should we address that?

<Zakim> bruce_bailey, you wanted to say i am worried about even 3 guidelines being complete enough

Bruce: I am worried about those 3 guidelines being complete enough to get substantive feedback.

<JF> +1 to Bruce

Jeanne: My point of view has always been that we are not interested in getting feedback on the specific guidelines as much as we are interested in getting feedback on the architecture and direction we are going.

Bruce: but we are not going to have conformance. the guidelines won't be complete or parrallel each other in structure and form. I think it will be hard for people not involved in the process to review and comment.
... This is the first time a lot of people will look at this and I am concerned they will be confused and alarmed.

<bruce_bailey> i am happy to defer to mc

MichaelC: My preference is that we get something out sooner rather than later. Let people see it. It has been in incubation mode. The advisory committee is pushing for more.Mechanically it is easier to publish future drafts. It also shows we were ready to proceed this charter.
... so I'd prefer incomplete but soon.

AWK: Please think about this. If you have thoughts and concerns, now is your chance to express them.
... we've heard a couple of concerns that there may not be enough to comment on, that we need editors notes to reduce confusion, the intention with the charter is to move forward the FPWD. The point of this call is to give a heads up on what the state of the document will be in when we see it in a month/month and a half.
... you will have another chance to review and comment. Any objections to moving to the next item?

ACT survey on new rule https://www.w3.org/2002/09/wbs/35422/ACT-Rules_Oct2019/results

AWK: ACT spec to be published soon. We wanted to have a rule to go with it. The ACT taskforce picked an "easy" one. The survey is a comment on this. It is a non-normative document like a technique. If we publish it tomorrow, we can fix it as fast as our process allows.

Maryjom: the overall strategy is to get these documented for various tests used for conformance. We want to get one rule out so we have an example to show how the spec works. There will be many more rules to come. This is to test the process.
... bring rules that community group and ACT taskforce has approved and then have the AG WG review it.

Wilco: It establishes where to look for rules. It says here is where the first is and this is where you look for future ones.
... all the comments are about the examples which is good - easily fixable. I will take it back to the ACT rules and community groups and propose an update and try to get them to sign off on it. I will then bring this rule back to AG as soon as we can. Likely a process of a few weeks since multiple surveys between.
... does that work for everyone?

AWK: It may be worth taking a few minutes to address a few of the comments. I was thrown back a bit when I reviewed this. Some of these pass and some don't pass. Can you speak to that?

Wilco: These rules set out minimal requirements. This is what you must absolutely do to not fail. When it comes to page titles, you need at least one title element. The title that is descriptive has to be the first title element. That works in the HTML spec and AT. It is not content for pages in iframes.
... Its a spec that works everywhere as far as we've tested it.

AWK: This is some combination of where the HTML spec specifies handling of titles and then it connects to accessibility scores because if the browser didn't support the conditions in the spec, the browser would not correctly report the doc title when the DOM is queried.

Wilco: We hopefully will have an example of this on iframes with lang attribute. In most browsers, if you set the lang attribute in the html it may not apply the lang to all elements.
... for title this works.

Ryladog: In the references section, do you want to reference the section in HTML?

Wilco: I think we did.

Ryladog: I don't see it there.

Wilco: Yes, good idea.

Ryladog: Other rules that have something relevant along those lines, this would help.

Wilco: We started referencing external specs in the reference section so we will sort that out.

AWK: Any other questions/comments?
... it sounds like the working group has provided some feedback and its a little more than MaryJo and Wilco can OK independently so they will go back.

<david-macdonald> Thanks to the hard work Wilco

Wilco: I would like to publish this rule as is and then update as soon as possible
... I think the changes are minor and clarification so shouldn't stop us from publishing this rule. This is a big milestone -- being able to publish this along with the recommendation which is publishing this Thursday.
... then we will come up with a revision.

AWK: The one thing I have the most trouble with is example #2. My reading of this is that it is not correct. It says that it is giving a title to the iframe when it is giving a title to the page that contains the iframe.

Wilco: I can change just that.

AWK: If you think that is the intention, that would make it editorial.

Wilco: Its editorial becuase it won't effect the outcome/implementation of the rules.

AWK: Anyone else have thoughts or anything they think would be a barrier

David and others: Thanks to Wilco, Maryjo and Shadi, etc for the hard work!

<Ryladog> +1

AWK: The plan is that the rule with the iframe change as discussed will be published and further comments will be routed through the taskforce for updates.

<Wilco> +1


RESOLUTION: The rule with the iframe change as discussed will be published Thursday and further comments will be routed through the taskforce for updates.
... Accept as ammended for publication

AWK: Thank you all again for all your work

<JF> Congrats to all on the ACT TF

AWK: We hope that after the first few, these will get easier but there is always a mix.

<Wilco> scribe: Wilco

<AWK> https://www.w3.org/WAI/GL/wiki/Scribe_List#2019_Scribe_History

AWK: everyone please sign up for scribing

Charter update

WCAG 2.2 Criteria review – Icon Description https://www.w3.org/2002/09/wbs/35422/icon-desc-acceptance/results

DMD: Concern on the last call was mobile. There is no hover or tab focus (usually).
... Instead of saying user interface control I came up with Primary action. If it has one, it will show on focus / hover. If it doesn't, than it shows on click or tab
... There was discussion about the word Icons, or Labels.
... the way I scoped it, for icons that don't have label, scope it out
... There is a question about if icons are ever instructions. My proposal is yes, for example a triangle exclaimation mark.
... If we drop out instructions we would drop out a whole category.
... I think 'instructions' is useful. We would lose a lot if we drop it.
... Take away is there are two use cases, and it scopes out if there is no visible label.

KHS: You are talking about instructions like an edit button?

DMD: yes. When you tab the action it shows the label for example.

AWK: What we are trying to say is there needs to be text for icons. If you have an envelope, and next to it e-mail, you pass.
... The way someone would design something is to pass the SC, rather than avoiding the SC to be applicable.

DMD: Some evaluators would say N/A, but WCAG doesn't have N/A, you pass an SC

AWK: Yes, if you have a page that doesn't have labels that are non-text content you pass

DMD: If we go to the different use cases it gets a little unwieldy. I wouldn't think you can put it in a note.
... I think we can leave all of that language out. It gives more space to talk about the primary action.

AWK: I was trying to get rid of the primary action part of it. The goal is that there is text available for the user. I was trying to avoid it including additional conditions.
... I was trying to simplify, trying to say that you have to have it. You want to make sure the text covers the image.
... I didn't know whether this would be SC content or note. What I like about it it doesn't have so much reliance on definitions, except ones that already exist.

DMD: I think we lost two things there.
... Sometimes an icon is not part of a control, so it's not a label, so that wouldn't be part of it.
... There was also a concern about hover and focus, that doesn't work on mobile. My goal is to get as much of it working on mobile. It has to be actionable.
... We would lose that if we'd go that route.

AWK: The other question, if you have an icon that is just intended to provide instructions, we're saying that it now has to be focusable.

DMD: Yes, that's right

AWK: For a screen reader they would land on a focusable element, that would indicate it was actionable. Wouldn't that cause confusion?

DMD: Yes that is a valid concern.

<Zakim> Wilco, you wanted to dispute that

WF: There are other ways to make labels visible, not just make them focusable

AWK: If there was only so much space, the solution would likely be to make the icons focusable

DMD: Most developers would do that

AWK: That would be the most likely way it was handled

<Zakim> mbgower, you wanted to say that I don't think this adds very little for any non-text icon that is a UIC. and to say that I think this adds very little for any non-text icon that is

DMD: If there would be something we could do for screen reader users .It's a balance

MG: If the icon is a UI component, it's by definition going to take focus.
... If it has a mechanism for showing the text alternative, I feel that is completely covered by existing SCs
... Non-text is covered by 1.1.1. Assuming it is exposed to anybody, it has to be accessible by keyboard. So if anyone can see what the text is called, it's covered by existing requirements

DMD: I don't agree. If you have a button with an edit icon and an alt=edit, you're saying that shouldn't pass?

MG: If the component takes focus, if it's not text it has to have a name, and if that's exposed to anybody, like a hover, than it's required to be accessible by keyboard.

<Zakim> AWK, you wanted to say that labels are for controls, instructions are not

DMD: This is the case where it's not exposed on hover.

AWK: David is talking about labels and instructions. Labels are about controls, instructions are not. For example the warning icon, today is not focusable, and this implies that it would need to be.

MG: Most situations are covered by existing SCs. There are not many situations where you hover over an icon and nothing is shown.
... One of these scenarios is almost entirely covered by existing scenarios.

DMD: Rachel left a comment about the title not being zoomed in. If we have this requirement in here, that includes all other SCs, so it applies to all other SCs.

MG: I feel this is apples and oranges.
... Unless we're using an argument that the title doesn't have to expand, because it's user agent.

DMD: You wouldn't be able to use the title right now. It doesn't zoom, not focusable.

KHS: If you're in Google Docs, in the bottom of the comment there's a star, if you hover it with the mouse, I can't get to it with the keyboard.
... When you tab to get to it, it shifts the title to the right.

<Zakim> Wilco, you wanted to talk about tittle and 2.1.1

WF: Would title fail 2.1.1?

MG: Yes, there is no way to expose it by keyboard if you are relying on the user agent

JD: I'm looking at my One drive list of files. The one note icons don't have a descriptor. When I hover over them I don't see a hover text. There is no way in the view to show what type of file this is. This is an example, having the ability to expose the text for this, that would be very helpful. Is that the kind of thing when you're talking about non-interactive?

DMD: Yeah, anything that's an icon should have the means to display text of what that picture means

JD: I think this applies to cognitive and low vision.

DMD: Yeah, that's in the understanding.

<laura> +1 to low vision benefits

AWK: Related to Jennie's point, if you bring on win / mac the file list, the file name doesn't necessarily indicate the file type. But someone implementing one of those, where there is a list, adding a column that says "type" would allow them to address this.

DMD: I think I have a gap in the SC for that
... the language I have no is really prescriptive.

<JF> https://w3c.github.io/personalization-semantics/content/index.html#action-explanation

JF: In the personalisation task force, what we're looking at doing is creating an attribute where you can apply semantic information to thinks like that. We're looking at a fix list of items that could be applied to those control triggers.
... We tried to do this in WCAG 2.1, and ended up with purpose of input. Partially we're going to have this up and running before the end of this year, as there are dependencies for 2.2.
... This ability to tag an icon with semantic data will probably not be in the UI, but it can use some helper application.

DMD: I like it, we can add a technique for that.

JF: The first draft has actions / purposes. In the case of an edit pencil, that would be an action. We have a fixed list of values, that includes "edit".
... There is a fair number of values. There are a number of terms that are at risk. I wanted to add this to the conversation.

<Zakim> mbgower, you wanted to say this is a result of going from a desktop app to web without having the desktop muscle

MG: We already have a situation, there is a requirement that a control has an accessible name. The problem is you can't expose this with an AT. I don't see how that solves anything. It's not like the user agent is going to do this.

JF: But the same can be said for ARIA, fi you don't have a screenreader, it's not going to be useful.
... Users will need to use tools that benefit them. We don't have a lot of tooling right now, but we are working with vendors to create tooling.
... If you dont' have a screen reader, and you use aria-label, that won't be exposed.
... we can't ask user interfaces to do everything for everybody. We want to encourage authors to create code to support different scenarios.

MG: That already exists. The piece that's missing is the ability to expose this.
... End users don't have the ability to expose this.


JF: I'm not sure that's the only reason.

DMD: I think it's useful.

MG: I think this comes from the fact that in a desktop environment we had icons that had a redundant means beyond the file menu to get to functions.
... If we tried to solve too much of that we create dissonance.

<AWK> +1 to Mike

KHS: We want to make things that can be used without a helper tool.
... A lot of people don't use this, including low vision.

DMD: Sounds like one of the things is some other way to expose stuff.

AWK: We should look closely to make sure it doesn't overlap with existing requirements

DMD: I think I've responded. Without that first bullet the other SCs don't apply. You can use a title but that wouldn't zoom

KHS: There's a user need that isn't fulfilled.

RESOLUTION: Leave open

WCAG 2.2 Find help https://www.w3.org/2002/09/wbs/35422/findable-help/results

AWK: Not too many people filled out the survey
... There were a few comments in the survey and on the document.

JD: I just started reviewing the comments. Don't have any questions at the time. Feedback is really good.

AWK: I think that the understanding content is great, helps understand the SC. But it makes the actual SC text more clear, and open to discussion about details of it.
... Bruce had comments about AAA, as there are content types where this isn't feasible.

JD: The COGA TF began this SC. One of the comments that came up regularly was the format that a chatbot often takes.
... In general there are two problems. The chatbots often don't understand when the person don't understand the expected format of the bot.
... For some individuals this is adding another layer of frustration.
... Another thing is having a whole bunch of links that creates a lot of frustration too.

AWK: If you have a self-help option, someone can look at it, and either their question is answered or it isn't. But the FAQ approach avoids the challenge of asking a question that isn't understood.
... But it feels like there is an easy way out, a link to an FAQ, or a support page, which might have almost nothing on it.

JD: It's certainly not equal, but what about a page that are no longer supported. There is for example a set of BBC pages that clearly state they are not supported.
... Also for the ones that don't need a lot of interaction, that would be an easy way to satisfy the SC.

<Zakim> mbgower, you wanted to say I think you can explain challenges of chatbot in the Understnading doc without all out forbidding them

MG: I think it would be feasible to cover the challenges of chatbots without forbidding it.
... In WCAG 1 JS was banned, because it wasn't accessible, but later it was.

JD: I'll take that back to the group.

<Zakim> AWK, you wanted to say perhaps we could scope this SC to pages that do provide support?

AWK: Did we consider scoping this to web pages that offer support?
... So if you have a website that doesn't offer support to anyone, that this SC is not required that they provide it.

JD: Yes, so a difficulty with certain cognitive abilities may have, some individuals may not be able to discern, how would they get that information?

AWK: Understood. A company that doesn't want to spend a lot on support could burry the link deep down into a submenu. That would satisfy this SC.
... I understand what this is trying to accomplish, but I'm not sure this is as achievable.

JD: This is why originally the text had a requirement for prominence. The difficulty is writing that in a way that's clear and testable. If you have suggestions that would be great.

<mbgower> I think you tackle the best practices in techniques and the Understanding

JF: It sounds like we're trying to have an influence over editorial content. That is problematic. I certainly understand the problem, and understand why the TF is struggling with it. You don't want to burry it, but we have to avoid being overly descriptive.
... I think best practices / techniques might be a better place to address that.

AWK: I agree, although I don't really want to. Some companies are looking at support as one of the value propositions, and others are focused on other aspects. I think we're trying to set what the bar is.
... What can we reasonably set? Does it have to be in a consistent location? Does it always have to be a person? There are different ones.
... The WG needs to think about this, from their own perspective.

<mbgower> It's tough to draft something that applies to both well-designed simple apps and something to apply to monstrosities

AWK: People who are not commenting, do you think it's all fine, or because it wasn't read?

Rachael: We need to push our own assumptions a little bit. We have to think a little more about content.
... This is tough, but I encourage all of us to think outside the box a little.

JF: It reaches the point that if we try to be overly descriptive, people won't do it.
... One of the reasons an SC is given A / AA / AAA is the impact on the content creator. We have to be mindful that not everyone is going to do stuff for the right reason.
... People do things because there's a legal requirement. It gets difficult if we make things extremely specific.

AWK: I wonder if ARIA has considered a support landmark
... Having some tool that would take you to support, that would be useful

DMD: I would say contentinfo is that. It's to provide contact information.
... We could just say this help has to be in the contentinfo role, but that's usually at the bottom of the page.

<laura> Agree with not being too prescriptive. Wonder if it could this be better handled in silver?

<JF> https://w3c.github.io/personalization-semantics/content/index.html#destination-explanation

trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. The rule with the iframe change as discussed will be published Thursday and further comments will be routed through the taskforce for updates.
  2. Leave open
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/10/29 17:01:43 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
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/approed/approved/
Succeeded: s/ACT draft to be/ACT spec to be/
Succeeded: s/expose it by keyboard/expose it by keyboard if you are relying on the user agent/
Succeeded: s/had a means to get to functions/had a redundant means beyond the file menu to get to functions/
Default Present: AWK, Jared_Batterman, MichaelC, Raf, Jennie, bruce_bailey, Wilco, Rachael, jeanne, mbgower, alastairc, maryjom, david-macdonald, JF, Katie_Haritos-Shea, Laura
Present: AWK Jared_Batterman MichaelC Raf Jennie bruce_bailey Wilco Rachael jeanne mbgower alastairc maryjom david-macdonald JF Katie_Haritos-Shea Laura
Regrets: Justine Chuck Detlev
Found Scribe: Rachael
Inferring ScribeNick: Rachael
Found Scribe: Wilco
Inferring ScribeNick: Wilco
Scribes: Rachael, Wilco
ScribeNicks: Rachael, Wilco
Found Date: 29 Oct 2019
People with action items: 

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]