Accessibility Guidelines Working Group Teleconference -- 27 Nov 2018

<alastairc> agenda

<AWK> +AWK

<AWK> +AlastairC

<AWK> +Chuck

<AWK> +AlastairC

<AWK> +JakeAbma

<AWK> +Brooks

<Rachael> Scribe: Rachael

takeup: item 1

Techniques update https://www.w3.org/2002/09/wbs/35422/TechniquesforApproval/

Technique: Ensure the "accessible name" includes the visible text

AWK: None of the items on the survey are unanimous so we will be going through each.

<JF> Dragon is available in JP: http://nuance.custhelp.com/app/answers/detail/a_id/14892/~/whats-new-in-dragon-naturallyspeaking-11-japanese%3F

<stevelee> the call is on? I enter password then the Join Meeting nutton is grey

AWK: 1 is ready, 2 needs changes, 3 needs discussion. Jake: Example X issue but will be fixed when we make it formal; Makoto, concerns about approach with Japanese language.

<stevelee> *button

<david-macdonald_> http://nuance.custhelp.com/app/answers/detail/a_id/14892/~/whats-new-in-dragon-naturallyspeaking-11-japanese%3F

AWK: Dragon is available in Japanese. Any thoughts on this since Makoto is not here?

Alastair: Is it how the example is phrased?

<Detlev> sorry to be late..

AWK: If there is a button that says "Read More" and an aria-label says "Read more about this article", I am unsure how Japanese would handle this.
... His concern seems to be that in Japanese it isn't in the same order. I'm assuming the Japanese version knows how to respond. I don't think we are saying that the string has to be first but in this example we say it has to be first.

David: It seems to be a common misconception that the technique tests for the technique itself not the SC

Rachael: Can we request Makoto create an example for Japanese?

I feel that the technologies being used determine the order. An aria-labelled by or aria-describedby will concatenate it at the end. Isn't this partially an implentation issue?

JF: At the end of the day, the short text on the screen is the call to action. We show the Western Language technique but in Japanese may be the last word in the sentence or phrase. In that case, aria-label since it would replace it. I do believe that Dragon is aria aware now.

There are multiple ways of doing that.

<JF> +1 to AWK

AWK: I think asking Makoto to think about an example that we could potentially test out, it does relate to the tech implementation. His example is send. In English we would state Send Mail and in Japanese it may say Mail Send. Both pass

<jon_avila> I agree with Andrew that change order would pass for accessible name.

Alastair to follow up with Makoto.

AWK: Mike has a lot. Both of us make a similar content. This technique has a lot of explanation, more than typical.

That is something that we need to think about. This seems more like an understanding document than a technique. We want to make sure our techniques do not restate the SC and provide specific detail.

David: Can we move the content over to the understanding document?

AWK: The description ends up being quick. If it unique to the technique describe it, but if its something like adding an alt tag, you wouldn't expect a long description.
... Do we want to move the content to the understanding document or do we need it in the technique?
... Do we need to describe the technologies or simply say that if it applies to technologies. Much of what is in here is covered in technique h44.

h44 is to use label and input associations correctly. I think many of the examples are also included. button text provides accessible name, etc. I think we can have a technique that says use standard labelling practices and then we need a technique to address the last two and Makoto's concern. What do people think of that approach?

<david-macdonald_> +1 with AWK

<Zakim> gowerm, you wanted to say that I think the crux of the technique is listing each of the kinds of visible labels and having an example of success for label in name (if it changes)

<alastairc> +1 move some to understanding, remove things covered by H44 but link to that.

gowerm: This document puts in parenthesis all the options. That by itself could be a technique. Then you could still remove items covered by h44. The five things listed in parenthesis are the crux of this technique. Address each and give an example of successfully doing that.

AWK: I had another question: Is the value of the input regarded as part of the label for a control?

David: No.

gowerm: For a button?

AWK: No. As this describes it, the accessible label is what is read, and when read the contents is read. With 412, the name is things, the value is 3.

gowerm: I don't think so.

AWK: Do you have additional concerns beyond the editorial needs for the content. Do you think the objectives should be longer?

gowerm: Not necessarily. I didn't like the word "exact string" as its written. I think it needs to be reworded.

<AWK_> "The control's accessible name contains the visible label without changing the order of the string of text or adding text within the string."

<JF> +1 to Michael there

AWK: I had suggested something regarding the failure that is similar.

It seems like those should be the same between the failure and technique. It should be the same phrase we evaluate against.

<alastairc> Yep

<gowerm> +1 to moving content to understanding and making technique more specific

It sounds like we agree this needs more work. That we need to look at h44 to see if we can slim this down, then also look at this with regards to the understanding to see if we can move content.

RESOLUTION: Address comments in the survey.

Technique: Using CSS width, max-width and flexbox to fit labels and inputs

AWK: There is a suggestion to add a resource section.

Alaistar: There was previous discussion to put one higher up.

Bruce: Usually resources should be an addendum but on this one, they are needed.

AWK: It could be both placs.

It sounds like this is not a huge issue for anyone. The only other comment is mine, Alastair and I need to go through and normalize how we define expected results for technique procedures. We used to do it as "Check #3 is true" This one says "Check that #3 is true." We should spend a few hours to update the style to be consistent.

Any objection to accepting this technique?

gowerm: When I filled it out, there was not input box.

I added in some minutia in the issue. See link above.

1. should be code tags in some places, 2. already qualified to being about preventing horizontal scrolling. In the 2nd paragraph, they talk about one column layouts it can say horizontal scrolling.

3. Similarly, where it says doesn't cause scrolling in more than one direction. It can say horizontal scrolling there. Also can we consider using "more than one plane" instead of "more than one direction"

AWK: I think it doesn't reference horizontal scrolling so it can apply to both.

gowerm: Yes but it lays out that it only addresses horizontal scrolling so we should consider changing the name to clarify this is about horizontal scrolling.

other small editorial concerns. The final issue is that adding the first few steps of the procedure to the working example to make it clearer.

I think the working title could be better. "Adjustable labels and inputs for reflow."

<Zakim> gowerm, you wanted to say Please see my comment in https://github.com/w3c/wcag/pull/509

<gowerm> For vertically scrolling content, all labels and inputs fit in their available space without horizontal scrolling

gowerm: The text is backwards. I think it should be "for vertically scrolling content, all labels and inputs fit in their avaialble space without horizontal scrolling"

AWK: Who worked on this one?

Jake: I heard everything so I can work on it next week and come back with an improved example.

AWK: It seems that the view is that its ready for publication with the described changes. I have most of them implemented with the exception of the title change and procedure change.

<gowerm> I can live with the title as is, but i think the technique title could be better

<JakeAbma> +1 to the changes

If that is all we need to do, can we agree that with the proceedure and title change we can accept it as ammended?

+1 to accepting it with the changes

<laura> +1 to the change as amended.

<Chuck> +1 to changes

gowerm: I think we should do the changes.

<JF> +1 to the changes

Proposal is to change it to "Adjustable labels and inputs for reflow"

or "Using adjustable labels and inputs for reflow"

JF: That makes more sense when you take it out of context.

+1 to second option

<alastairc> +1, don't mind about 'using'

AWK: Any objections?

<Mike_Elledge> +1

<laura> +1

AWK: The next piece is the procedure. Mike, if you walk us through that change it would be helpful.

Alastair: I think steps 1 and 2 align with other items.

<gowerm> For vertically scrolling content, all labels and inputs fit in their available space without horizontal scrolling

gowerm: For the procedure only step 3 needs to be change. The text is above.

AWK: I think you can refresh the technique.

gowerm: Other than that, if Jake can go through and check the minutia.

AWK: I think I have fixed that.
... Looking at the procedure, is that all correct?

gowerm: Does the word check need to be in expected results?

AWK: We will correct that and the working example title.

The font will correct itself when the code refreshes?

gowerm: Should I create a new branch when I have a lot of detailed changes?

AWK: It helps.

Any objections to accepting this as ammended?

RESOLUTION: Accept Issue 456 as ammended

<AWK_> AWK and Alastair need to make sure that the file name for the working example are updated.

Ensuring that drag-and-drop actions can be cancelled

aWK: 3 say its ready, 2 say needs discussion

May need to be more granular. Should we make the undo and dialog portion one technique? Then make the dragging a second technique so this can be more concise?

detlev: Because it is a failure, you want to check that multiple ways for cancellation are used.

AWK: Not a failure technique. At least it says it isn't. But I agree and it makes failure techniques for items like this nearly impossible to draft because there is always another way.

detlev: I'm not sure how useful this is for authors.

AWK: I also went back and forth on this. It seems like this is then entire SC but its actually not since that is pointer actions and this is only drag and drop.

detlev: would someone putting together a drag and drop interface want it one technique or multiple?

AWK: What do other people think?

Perhaps not as many people got to this one.

AWK: I take your point and they are related to one specific type of pointer action. I don't object in that case but what do other people think? Leave it as it is or otherwise?

Bruce: I'm ok with it.

Alastair: I also think its wide but I can't think how to fix it.

AWK: General techniques tend to be that way. Its not a specific technique. This is much more general.

gowerm: I will have some editorial changes.

I haven't finished reviewing it but just the stuff at the top in parenths was a bit odd. The changes seem trivial.

AWK: If you find them, we can edit it if the group accepts. Any objection to accepting it as proposed?

RESOLUTION: Accepted as proposed.

Technique: Failure due to "accessible name" not containing the visible label text

<alastairc> scribe:alastairc

<Detlev> fine, remove web

AWK: (Running though own comments in the survey)

<JF> WFM

<Detlev> what is WFM

AWK: (adjusting the objective text, from comments)
... need to specify 'accessibly hidden', i.e. really hidden from everyone, or visually hidden only.

<Detlev> fine with change

<Rachael> s/ RESOLUTION: Accept Issue 456 as ammended / RESOLUTION: Accept as amended

<Rachael> s/ TOPIC: Ensuring that drag-and-drop actions can be cancelled / TOPIC: Technique: Ensuring that drag-and-drop actions can be cancelled

<Detlev> AFC for one minute...

gowerm: Not sure about the title of second example , could it be "disrupts..."

AWK: how about accessible name contains additional text?

gowerm: problem is interfering with the string.

AWK: Other question, in procedure the examples in the first sentence need checking, value of input?

Detlev: not sure.

JonA: Only when part of accessible name calc, so wouldn't include it without that aspect included.

AWK: Name calc wouldn't affect visible label. E.g. search which includes default (not placeholder) text, would that be part of the label, or just the 'search'.

JonA: If we say the default text is part of the label then we set a precedent that it's always part of the accname.
... I can see some rare cases such as a filter it would be difficult. You'd agree we take value of input out of the procedure?

AWK: Any objections to taking 'value of input' out of the procedure?

<Brooks> For a rename of the second example, how about "Invisible link text disrupts visible label text string in accessible name"

gowerm: From the accname spec, not sure what it means on this aspect.

<AWK_> "The control's accessible name contains the visible label without changing the order of the string of text or adding text within the string."

<gowerm> I think #2 is okay as is.

Brooks: See sentence above for example 2.

JonA: Not sure about 'disrupted', more about a parsing issue.

<gowerm> The accessible name contains a match for the string of the visible label

gowerm: More for the procedure than the example

<gowerm> The accessible name does not contain a match for the string of the visible labe

AWK: That's ok for step 2.

<Ryladog> encompasses?

AWK: For failures, do we make the procedure steps positive or negative?

<Ryladog> encompasses the label name

AWK: think I've got that in place (refresh preview).

gowerm: Not an 'and' case.

AWK: If the accname is the same, the first is true, the second is true. If they are different but a whole match, the first would be false and second true. That would be ok.
... if check 1 is false AND check 2 is false, then content fails.

RESOLUTION: Keep open

Technique: Failure of Success Criterion 1.4.13 due to content shown on hover or focus not being hoverable

https://rawgit.com/w3c/wcag/tech-failure-content-hover-focus-not-hoverable/techniques/failures/tech-failure-hover-content-hoverable.html

Detlev: I think I got this one wrong, ignore the comment.

AWK: (Talks through technique)

<Zakim> gowerm, you wanted to say there is a problem and to say that if there is no ability to use a pointer, this shouldn't fail, which would in the case of how the technique is worded

gowerm: Wording of the title, if my system doesn't have a pointer it would fail automatically.

AWK: If you have something without a pointer, nothing appears without a pointer, that's ok. If you don't have a pointer, you don't fail.

gowerm: Logically, I can make content appear on focus with keyboard access, but the way the title is worded I have no ability to hover.
... maybe that's a closed system issue?

Detlev: For general web content, have lots of scenarios where it would apply. In a closed system, wouldn't apply so wouldn't be in scope.
... there is a case, where it can appear on focus, where a mouse should be usable.

AWK: Is there a problem? If we make the statement positive, "the pointer can move over the content".
... if you have a system without a pointer, would you fail it?

<AWK_> For each area of pop-up content that appears on hover or focus events: 1) A pointer can move over the new content without the content disappearing.

Detlev: Just thinking, including keyboard focus gets complex, could have mouse-trigger events as well. Wise to keep to pointer-hover only.

AWK: Could add a 1st step, check that the system has a pointer?

MichaelC: Applicability section, e.g.systems which have pointers.

Detlev: Would only apply to situations where hover over a trigger has triggered a pop-up. Easier to tie it to the scenario.

<Detlev> yup

MichaelC: Detlev's version should go in the procedure, and add something to the applicability.

AWK: Same issue with sytems that have pointer but no keyboard.
... the applicability and/or test procedure need to account for that. Or take on faith that people won't try to evaluate this in strange ways.

MichaelC: No faith in that!

JonA: Scope to the scenario, triggered by hover in the first place.

(People look up the SC)

JonA: Hoverable/persisent/dismissable.
... We talked on github, you can hover with a mouse, want to dismiss with keyboard, but may not be focused.

AWK: The hover bullet doesn't mention keyboard at all.

gowerm: Could have another failure technique for being able to dismiss it without moving focus.

AWK: Should make this about the pointer-only, not keyboard. Other things needing to pass, but if you fail this one, you fail.

<Detlev> Just as a reminder, there is still a call for help on https://github.com/w3c/wcag/issues/529

gowerm: Can I ask a question on this topic that isn't on this topic?
... for dismissable, could you have a technique where you don't have a keyboard method for dimissing with the mouse.

<Detlev> @ mgower: Sounds like a valid option

JonA: potentially you need another option for touch screens.

gowerm: another little puzzle there.

<Detlev> yes

<AWK_> For each area of pop-up content that appears on hover or focus events: 1) A pointer can move over the new content without the content disappearing.

AWK: If we're switching back to just behing hover, I put in text for this.

JonA: Use term "additional content" specifically, part of the SC text. Doesn't have to be pop-up, which implies tooltip. Could be non-modal.

AWK: Made a few changes, which we can take a look at if the refreshed content shows up.
... https://rawgit.com/w3c/wcag/tech-failure-content-hover-focus-not-hoverable/techniques/failures/tech-failure-hover-content-hoverable.html
... (reads change)
... The examples do talk about pop-ups, which is fine for an example.

<laura> +1

AWK: what do people think?

<bruce_bailey> +1

<JakeAbma> +1

<Ryladog> +1

<Rachael> +1

<JF> +1

AWK: any objection to accept it as ammended?

<gowerm> +1

<Detlev> +1 :)

<david-macdonald> +1

RESOLUTION: Accepted as amended

<AWK_> Alastair - we should change the title to "Failure of Success Criterion 1.4.13 due to content shown on hover not being hoverable"

<AWK_> to "Failure due to content shown on hover not being hoverable"

Failure due to "accessible name"

<AWK_> https://rawgit.com/w3c/wcag/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html

AWK: Updated version visible now.
... Updated example title 2, procedure steps start with accessible name.

gowerm: Are folks ok with the parenthese?

AWK: Can we remove those?
... sorted colons & commas.
... any further edits?
... any objection to accepting as ammended?

RESOLUTION: Accepted as amended

Any other business

AWK: Great progress getting these techniques & failures done, let's keep moving.
... any other questions/comments/thoughts?

<laura> bye

trackbot end meeting

- DRAFT -

Accessibility Guidelines Working Group Teleconference

27 Nov 2018

Attendees

Contents