<AWK> New member Jared Batterman, for Mitre
<Jared_Batterman> Thanks!
<Rachael> Scribe: Rachael
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/
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?
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
+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
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.
+1
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
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
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]