Accessibility Guidelines Working Group Teleconference -- 25 Jun 2019

<JakeAbma> scribe: JakeAbma

Next week's call

<alastairc> No call next week

AWK: next week no call, but please feel free to work on items

sending regrets

AWK: people don't send regrets to editor list lots of times, some do
... anyone cares? or isn't it a problem?

MG: not really and issue

Laura: also no problem

<alastairc> I don't really care, email threading solves the problem for me.

AWK: so we need not to worry, yey

Charter discussion

AWK: we had some people saying milestones to ambitious, had a talk with Silver folks

AC: very optimistic timeline will bring us to 2022
... general feeling Silver folks is happily get to recommendation for timeframe charter

AWK: Silver will be mentioned in charter for RECcheck
... not expected to Recommendation
... if we get pushback and only get 2 year, we'll make less progress
... doesn't change charter for 2.2 but does for SIlver work

JF: still aggressive, but can live with it
... concern about conformance model
... not all share this opinion

DmD: good not to set a date
... good to have open ended and intention, but needs to be solid before replacing

<laura> +1 to david

JF: if Silver not make it, a 2.3 might be possible
... just to be sure we don't rule out the possibility

AWK: we don't rule it out, but we focus now on the next charter
... we'll update the charter draft accordingly

MC: we'll have a CFC for that

RESOLUTION: WG agrees to update the charter to include Silver but not including REC and to use that draft as the Wide Review Charter draft

WCAG 2.2 SC reviews (Q 2-3) https://www.w3.org/2002/09/wbs/35422/wcag22reviews/results

AC: Katie would like new SC
... Bruce provided 4 options, also a new one, and current one to A
... Jake thinks it's goof for this SC, not a new one

AWK: we can have another one "enhanced"
... and if that one is there, we can remove the current
... what are the advantages?

JF: changing / removing is not my preference, adding another one and make other ones redundant in future might be ok. But removing one also doesn't feel right.
... don't mess with current one, improvements should be new SC

AWK: this might be problems with tools?

JF: you can flag them, may add stricter rules
... no problem to add, but the old ones need to stay

DmD: clarification for focus visibility might belong in 1.4.11

AC: non-text contrast struggled with changes
... wasn't really good for transitions
... a feasible test with adjacent colors was an issue
... now wanted to have it about the change of color, not difference with adjacent colors

MG: see the issue about backwards compatibility as JF sais
... said

JF: making a AAA a AA is no problem, we just tighten up WCAG then
... the concern is we change a triple to double and then say we need to remove another, that's the problem

DmD: are we hitting a three way contrast ratio AC?

AC: no we don't

<Zakim> alastairc, you wanted to talk about the separation of the SC

AC"doesn't have to have contrast 3:1 with component, only change of focus itself

<alastairc> https://alastairc.uk/tests/wcag21-examples/ntc-focus-styles.html

<alastairc> David - see boundaries section in the understanding: https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

<Jon_avila> I disagree with Alastair - since a background is there It needs contrast

AWK: if they are on the same level I don't see a problem
... if we move 2.4.7 to A, we might get questions

<hdv> /me I have to drop out early

<Rachael> scribe: Rachael

<AWK> Setting a 5 min timer on this topic, FYI

alastair: We have compare and contrast with surroundings - that is where we talk about adjacent colors. With regards to adjacent we talk about the change

Detlev: If the button is on the background with different colors and it overlaps different backgrounds, do you take the lightest color? Do you take a certain part where the focus is very visible?

Alastair: That is a good question that brings us to the sizing aspect. Are we done with the contrast portion of this?

AWK: I think we should timeout on this discussion. We are trying to collect concerns not resolve all issues.
... I don't want to spend the entire call on this review, which we could. Do you want to speak to the size quickly?

Alastair: There is always a question of how big a focus indicator should be. I am trying to create a mechanism for sizing that is visible but not too difficult to test.

I suggested we have a sizing mechanism. Set minimum size by creating a box. The surface area of the focus indicator should be at least the same size as the control.

AWK: An underline would suffice but a vertical bar next to an item would typically not.
... questions about that?

<Zakim> AWK, you wanted to talk about default focus indicator

AWK: There is a note about the default focus indicator is not sufficient. I think its worth thinking about the browser default focus may be sufficient but the responsibility is on the author to ensure the default satisfies the conditions.

<mbgower> +1 to awk

JF: I sort of agree with AWK point about browser defaults but I have concerns about looking at it from the author's perspective vs. looking at it from the users' point of view.
... just because it conforms in chrome doesn't mean it works in FF.

<Zakim> alastairc, you wanted to ask why it isn't backwards compatible.

Alastairc: Given this is increasing the requirements, I see it as backwards compatible. Is that OK?

JF: Both Katie and Bruce have mentioned that they are comfortable at AA. Even if this new AA overrides a previous AA or makes it redundant, that is what understanding documents are for. We can say that in an understanding document without it changing the normative specification.

<david-macdonald> "padklc

AWK: Good discussion. Key items: Placement, questions around whether to modify 1.4.11 or whether the specifics of contrast are the right measures.

Make it Easy to Find Important Controls

<alastairc> Rachael: Started out as 'making the most important things visible'.

<AWK> Rachael: (details overview of SC - https://docs.google.com/document/d/1DPtCqWHjrhj3QZ4afsqzmWDd-zMSf39RsMqSpR2QGCg/edit)

<alastairc> ... decided to focus on essential controls.

AWK: 7 have some concerns.

Jake: Menu items in mobile items can be hidden. They can't be put on the screen by definition. The AAA would still not be possible because there are more buttons than on the screen. And below the fold is difficult in moving from desktop to mobile.
... I see where the issue comes from but difficult.

AWK: So concerns are on what constitutes essential.
... Zoom can also cause challenge. Concerns around determining how far from the top is OK and determining what controls are essential.

Jake: Also landscape may present an issue.

AWK: Orientation is also an issue.

MichaelG: Can we come up with a programmatic indicator for important controls? Present visually information based on the programmatic indicator.

Alastair: Suggest rather than making things required to be visible, make them available. Controls could be behind a hamburger to help mitigate the without scrolling portion.
... defining any fold or visibility without scrolling is difficult. As to how we define essential controls, Controls which are essential to the page's task?

JF: This problem is being worked on right now. The personalization taskforce is working on this. New attributes for purpose, actions, and destinations. The taxonomy would allow the critical ones to be tagged. The issue is that we don't have a mechanism.

JakeAbma: If they are working on it, can we stop with this SC? Don't we need to have an accessibility supported way currently?

AWK: There have to be existing implementations.

Jake: Can we continue with this SC?

<JF> Proposed (draft) "ACTION (button/control) taxonomy terms here: https://w3c.github.io/personalization-semantics/content/index.html#values

AWK: If we are looking for implementations, it is a risk but not necessarily a hard stop.

Stevelee: This SC is written for content creators and relies on the author to determine which are essential. It may not be possible in every situation. Are we hoping that AT will automatically make it visible?

AWK: To restate, if the personalization semantics was available, that would solve this?

<alastairc> Having an attribute to add means the author can define what is critical, but without that you need an objective(!) method of defining what critical is.

SteveLee: That seems to be what is indicated. The AT enhances the presentation based on user preferences.

<JF> Wrong analogy AWK... think user style-sheets: if you supply the semantics, the end user can manipulate those semantics

AWK: If the technologies didn't support the alt attribute, then using alt wouldn't work. It doesn't mean that all tech needs to support it but that there is some path forward.

"Controls needed to complete tasks on a page must be clearly indicated and available through location, visual presentation, and/or programatic markup."

<alastairc> Rachael: The intent was to easily ID want to do next. Can we step back and take it to techniques to meet it, and move to something like...

Rachael: Is that a path forward?

<Zakim> mbgower, you wanted to say that Status Messages may be a good thing to look at

AWK: People come up with immediate questions about how do we do this more than text alternatives. This is new enough ground that a broader approach might help.

<AWK> Setting a 5 min timer on this topic

Mbgower: 1. I think you should have a look at status messages. It is related. Status messages needed to have some aria ability to work. They depended on an assumption that the designers new what they were doing and created a modal that forced the user to interact. That when the designers didn't take the focus they were not as important.
... we waited until the aria-attributes were in place and being used so we could it happening in the real world though not all aspects of aria has been adopted. We made an assumption that designers were using certain components to indicate important. Then used those things to make it testable.

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

JF: When I go back and look at the document, the test criteria requires "identify essential controls"
... the personalization task force has started defining what are essential controls.
... MikeG mentioned aria where we took the semantics and used them. If you don't have a specific criteria for testing. Right now, we place the onus on the author to determine what is important. It needs to be specific.
... We need to make essential controls are findable or discoverable.
... when you get more complicated widgets. The problem is that I don't see a strong programatic way to meet this content. It relies on physical layout.

Jake: programatically determinable and above the fold are different things.

<Zakim> alastairc, you wanted to say that without an attribute we have to define important objectively, which is really hard.

Jake: programatically determinable requires AT. The layout is more of a design issue. Most important controls are already designed above the fold or recognizable. I think we need more discussion of the problem and how to solve it.

Alastairc: The programmatic determination makes it easier. Without that, the SC needs to define what is critical in a way that a tester can identify what is important.

AWK: Good suggestions.

zakim next item

WCAG 2.1 Techniques (Q 1-5) https://www.w3.org/2002/09/wbs/35422/Techniques-June-2019/results

Technique - Tech Control Orientation

AWK: This is a general technique. 4 people agree, 1 feels it needs changes.
... Jake comments that we need more examples but this is a general technique so speaks more generally.
... I addressed your other editorial comments and tweaked the wording. If you can take a quick look at those and let me know if those address your concerns.
... Did anyone have other concerns they want to raise?

mbgower: I am not entirely sure this meets the letter of the SC. The author is restricting the orientation as written.

<AWK> "Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential."

mbgower: As written, this is allowing the author to restrict the orientation but providing a button to allow the user to unlock the orientation.

AWK: The content overall is not restricted but some content can be restricted but there must be a path to allow users to unlock the restriction.
... we have a note that states the best way to deal with this is to not restrict it.
... the taskforce had suggested it.

Jake: I think its interesting because I have a specific problem with the wording of orientation and the understanding document. I've added an issue. It is clear that we don't want to lock a view but restricting a view may be needed.
... See the Github issue I added. The text is not clear so we need to revisit the understanding document. When we talk about the next technique, there is a big difference between the text and the technique.
... on orientation there is a change of context. Similar to on focus.
... all content must also be available in all orientations. Pandora's box.

<JakeAbma> https://github.com/w3c/wcag/issues/799

AWK: You are saying you have much greater concerns than just this technique.

<mbgower> On consideration, I'm fine with this first Orientation technique, but I think it needs some editorial work.

Jake: It may be because of the ways we created the wording. It's a good technique if we change it to lock.

AWK: We had a long conversation at TPAC about not using lock and we can't change the SC text now but we can address it in the understanding documents.

David: If content appears when orientation changes, testing is done.

<Zakim> mbgower, you wanted to say I'm happy to take a crack at a draft of the 2 orientation techniques

Jake: There is also an issue about width and height. We need to be clear in the understanding document. Its not clear right now.

mbgower: I am happy to take a pass at the orientation techniques for the next draft.

AWK: Are you saying that there is something specific that needs to change?

mbgower: I think the wording needs reworking though the general approach seems good. I'm not suggesting changing the direction just improving it.

AWK: So mbgower will take a pass on this and the failure technique.

RESOLUTION: Leave open Tech control orientation

Technique - Tech Failure Doorslam

Jake: If we take orientation as we move from portrait to landscape and the content doesnt' change it is a failure. The doorslam technique is interesting because it changes context based on orientation.
... So there is a content change instead of locking based on orientation.
... I also added a specific link somewhere that asks you to rotate your device and then replaces it when rotated. Screen orientations, device orientation, and desktop where the device is the same but the monitor rotates.

AWK: Apple used to have different content in their stock application based on the orientation. An airline example also showed content in one orientation but asked you to rotate the device in the other. Some have argued that the orientation isn't restricted just different content.
... now in the stock application, everything stays the same but you view your content sideways.

<Zakim> mbgower, you wanted to say that not locking orientation has nothing to do with content changes

<alastairc> This page has a box partway down that insists on landscape: https://www.digitalrev.com/article/fuji-gfx100-v-gfx-50s-9-key-differences

mbgower: I don't think orientation as anything to do with content. What you are describing sounds like the reflow error. If you pass reflow, then you likely won't have that issue.

Jake: I checked reflow and it doesn't fit.
... This isn't talking about reflow but we discussed at TPAC about content replacement. We have a mix about what we mean by orientation and we are not clear in all parts.

mbgower: It sounds like you are talking about a new SC.

Jake: You can see what I've gathered. The more you get into it, the more we need to be clear about what we mean where.
... specifically about the word "display"
... device orientation is landscape/portrait. Orientation within frames only means width and height ratio.

RESOLUTION: Leave open Tech Failure Doorslam

<mbgower> I'll have a look at issue 799, opened by Jake

AWK: We will need some clarification documents to go with these techniques. We are not meeting next week. Any parting thoughts?

mbgower: Are we keeping any kind of high level change log of new techniques so we can keep track and reference?

AWK: We do but I will need to look for it.

Alastair: Its off the techniques page but it may be out of date.

<scribe> ACTION: Update techniques page

<trackbot> Error finding 'Update'. You can review and register nicknames at <https://www.w3.org/WAI/GL/track/users>.

trackbot end meeting

- DRAFT -

Accessibility Guidelines Working Group Teleconference

25 Jun 2019

Attendees

Contents