Accessibility Guidelines Working Group Teleconference -- 07 Aug 2018

<Glenda> scribe: Glenda

Process discussion and feedback collection reminder https://lists.w3.org/Archives/Public/w3c-wai-gl/2018JulSep/0131.html

<alastairc> https://www.w3.org/People/Brewer/

AWK: Quick reminder. We are collecting feedback on the working group process. We have heard from 8 people so far. This is still open. If you have feedback, please complete this survey or send an email.

Silver review delay

AWK: Silver wants us to hold off on review. They will have a new draft sometime in August. It may not change radically. It is a continuing evolving document. So, we have closed the survey for now…wait for the next version of the doc.

Techniques needing work/review

<AWK_> Github link: https://github.com/w3c/wcag/pulls?q=is%3Apr+is%3Aopen+label%3ATechniques

<kirkwood> +1 to working calls

AWK: We have a number of things ready for review. Encouraging people to please review. We can’t get these published without some review. What would help people carve out the time. Should we have a working day call?

<Ryladog> F2F is what works

<AWK_> Glenda: want small group working calls

<AWK_> ... needs to be focused

<AWK_> .. too many would not be as efficient

gowerm: nice to drive one to completion, so we could have one done (so folks can see the process)

<kirkwood> +1 Agree witth Glenda. Agree having one done to see a format and example

Chuck: what was done in WCAG 2.0?

MichaelC: We broke the group up into 3 teams (Team A, Team B, Team C) and had facilitators in each group with specific “to dos”

marcjohlic: could we grab a technique and try to wrap up one of them?

<AWK_> https://github.com/w3c/wcag/pull/386

AWK: Yes. Let’s try to find an easy technique to do. The one I tried was Text Spacing Override - it has proven to be quite complex.
... as I added an example of a paragraph of text, I was having rendering problems with stylish and Safari.

<AWK_> https://github.com/w3c/wcag/pull/386

<AWK_> https://github.com/w3c/wcag/issues/384 for the discussion

Alastair: Safari doesn’t work well with those plugins. If you use custom stylesheets in Safari, it works as expected.

AWK: Encouraging. Does it matter if the width is defined for a container, does it blowout the design? Longest word for example is “conversation”.
... technique for examples 1 and 2, are about providing enough buffer so you don’t run out of space when the user makes changes.
... example 3 is about flexible container dimensions so you don’t run out of run, because it is able to wrap and extend the container vertically for western langs.
... feels like 1 and 2 examples should be 1 technique. And example 3 should be broken out into a 2nd technique.

<marcjohlic> +1 to Gower's 2

AWK: any other techniques ready for review? Suggest starting with gower’s Example aria role status https://github.com/w3c/wcag/pull/431

<marcjohlic> +1 let's do it

<AWK_> Rawgit: https://rawgit.com/w3c/wcag/tech-using-role-status/techniques/aria/aria-status-role.html

<alastairc> Thinking the procedure be a "for each" status message?

<Zakim> JF, you wanted to ask about whether this is or was taken from the ARIA WG examples?

JF: This looks good. ARIA working group has a huge collection of examples. Does the ARIA working group have a specific example that supports this?

<Zakim> MichaelC, you wanted to say unclear if description is descriptive or prescriptive and to note aria-label on ex 2

MichaelC: I can’t tell if the description is telling the author what to do. After the first sentence, insert, “This is done by adding role=“status” to the element that includes the status message.”
... on the suggestions aria-live of polite, and aria-atomic of true (explain you can change that when needed)

<alastairc> Michael - the aria-label would override the content of the element

<Zakim> bruce_bailey, you wanted to say that I think more qualifications are needed for checks

Michael: on shopping cart example, aria-label completely overrides, so the 6 items would need to be added to the aria-label attribute value to be read.

Bruce: I think the procedure needs to be expanded for testing.
... lots of assumptions. Make it so a person who is very new to aria could follow the test procedure accurately.

Brooks: Make sure the label is available in the status content.

AWK: If only the updated text of a shopping cart is going from 4 items to 5 items, and all you hear is “5”, does that pass. I think it does.

Brooks: that is based on the action of a user, so it has context. not all status messages will have that context.

<alastairc> MichaelC - I thought the same about aria-label overriding the label, but that isn't the result I get in VoiceOver, need to check the accname calc, but it's rather complex https://www.w3.org/TR/accname-1.1/

gower: a lot of this info people want can be found in the undrestanding. Sounds like people want it repeated in the technique document?

AWK: I like the techniques that are concise. (not explaining why it is important)?

gower: working example is not identifical to the code snippet

AWK: where we can, it is good to make the example match the code snippet exactly.

<WayneD> I lost Webex, but I think Micheal C was trying to get at the order of presentation. What is to be done must be at the top so the description can explain the actions.

Trigger each status message and confirm that the newly added status message is announced by a screen reader.

<WayneD> Yes, what Glenda just said is what I had in mind.

<Zakim> bruce_bailey, you wanted to disagree about AT testing

<alastairc> Generally better to test the content rather than via AT. Generally prefer acc panel or similar

<AWK_> for comparison: https://www.w3.org/TR/WCAG-TECHS/ARIA4.html

AWK: in agreement with Bruce’s comment. AT/Browser pairing can lead to very different results.

<alastairc> sorry, didn't intend to name a tool in the technique, but we need that as an assumption for code inspection

<alastairc> e.g. Example 2 has a role of "statusbar" in the panel, therefore it has worked.

Can we add “inspect the code”

Brooks: whole purpose of this SC was to provide AT announcements of status message without getting user focus. So if you don’t move focus…you need context of what that message is about.

gower: hard to determine what is appropriate for context

Brooks: example of what would not be okay - situation where the user didn’t take an action, but a status message appears. You get just the new status message, but you don’t know what that status message is related to (since focus did not change). Like on a auction bid site, and bid changes. And you just randomly hear “99” because that is what the bid just changed to.
... the context as described here: “Because the shopping cart icon adds visual context, a label is added with aria. A screen reader will announce "Shopping cart, six items".”
... looking for role=“status” isn’t enough. You need enough context to give that status announcement meaning.

<JF> +1 to mcooper

MichaelC: suggest pointing them to please look at the ARIA authoriing practices for the details.

+1 to MicahelC

JF and gower, is this the example y’all are looking for? https://www.w3.org/TR/wai-aria-1.2/#status

AWK: getting back to Brooks’ context of status message concern.

gower: when adding something to the shopping cart…which is okay? okay to just hear “4, 5, 6”. Or should you hear: “shopping cart: 4 items”, “shopping cart: 5 items”. I think 4, 5, 6 would be enough. The second option is a best practice.

<Chuck> Scribe: Chuck

<alastairc> Glenda - that's the spec, can't seem to find anything in the 'practices' for 1.2 https://www.w3.org/TR/wai-aria-practices-1.2/

Wayne: I found confusing (Michael put his finger on it), it didn't start out with... I heard Gower say things that need to go up top. Explains why you need actions to take place.
... I found I had to get deep into it before I had a feeling of what was expected (as I was reading it). As a person applying the technique I might not know what I need to do.
... I think stuff needs to be moved up top in the description so that the goal is clear and the description follows. I think it would help.

<Zakim> AWK, you wanted to suggest "This technique uses the status role from the ARIA specification to notify Assistive Technologies (AT) when content has been updated with information

AWK: I wrote earlier... relates... I suggest we make the beginning of this technique uses.... <tech talk>...

Wayne: Precisely.

AWK: BTW... those of you looking for best practices, I'm texting with James Nurthen, he's a chair on Aria, and he's digging for us.

Gower: I found lots of alert roles, but not much in the way of status roles

JF: My problem too, I've been searching in the background. Maybe we should be using the Aria working group in Aria techniques.

AWK: We can certainly throw them in review. Also given our process allows for additions, edits, removals... assuming that we aren't embarasing ourselves...

<alastairc> MDN has something, not complete, but something: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_status_role

<Brooks> +1 to JF's recommendation to include ARIA working group members in the loop when formulating ARIA techniques.

AWK: We can fix minor issues. I don't want Aria WG to say they need 2 or more weeks to review.

<WayneD> I need to leave. Bye. We have water rationing and I must water my plants now.

AWK: For the description, do people like the text I was suggesting? MG?

<bruce_bailey> +1 to AWK text

AWK: We do point people to the 1.1 Aria status roles for more details. For the tests, this is the q we had before.

<AWK_> "For each status message presented on a page:"

AWK: What I would suggest is we start the test procedure with Alistairs suggestion, with each status message on the page.

<AWK_> 1. Check that status container has a role of status before the status message is triggered.

AWK: And then I was thinking that if we had Item 1 being "check that status container has a role of status". IRC is not showing that it's got mono space font for status.

<AWK_> 1. Check that the status container has a role attribute with a value of status before the status message is triggered.

AWK: We'd have to have ... defined so that we know it's an attribute. "Check that the status container has a role attribute with a value of status" for the status messages triggered.
... I'm thinking that if people agree with MG says in that you just have to have the content that's updated, and if people agree with Brooks that context must be conveyed as part of SC...
... Then we need to have another item. We are at a decision point for that. If people think that the context isn't required in this SC, q is if it's required in others.

Gower: We have another consideration, what gets put in the container. Does it get wrapped around the label... the image of the shoping cart?

<bruce_bailey> friendly edit: Check that the status message is in a container that has a role of status...

Gower: We have a way of putting in a check of what's inside the container. Does the container contain visual context or something like that.
... Do elements inside the container have sufficient context for the user? That's pretty subjective and gets hard to ansewr.

Brooks: Check that elements inside the container provide sufficient context for the user. I'm trying to find an elegant way of saying...
... If there's something necessary for context, put it inside the container.
... I understand the question I can take a shot at this offline.

<AWK_> "2. Check that elements inside the container provide information equivalent to the visual experience for the status message."

AWK: How about... (text provided)

<Zakim> bruce_bailey, you wanted to ask if rawgit can update fast like media wiki?

<alastairc> Bruce - I don't think so, it is more or less a proxy server, it's github that is slow

<bruce_bailey> thanks Alastair

Brooks: ... but also that that content isn't overwritten by aria in the parent... If you added aria label to that container, it will announce the value for aria label.

<alastairc> hard refresh can help

Brooks: Has list of auctions won and auctions lost. If "3" is announced, do you know if you are in "won" or "lost"? If no context, it breaks the whole utility of this SC.

AWK: Does this line help with what you are suggesting?

Brooks: yes, and thanks Mike for coming up with this. And I agree with the direction.

AWK: It's thankless :-)
... Everyone gets a turn, should be nice in comments.
... Other people think....?
... Good point has been raised about context.

Gower: Information was there and got lost, and I'm going to be adding it back in. This does go into the realm of design, but it does address this to some degree.

AWK: I do think that if the only indication of a shopping cart for a site, a little circle with bold dark text in the corner that just had the number, and there's nothing else...
... If you provide a lousy visual experience, then a poor accessibility experience will occur.

Gower: Some nuts and bolts questions. Working example should be done as a pull request. But now there are two pull requests related. How do we go forward?
... Should ... <discusses different techniques>

<alastairc> +1 for together, did MichaelC have a concern about that?

AWK: My preference is that they come together so we have one thing. When I look through this list, 431, and 432 is the example, it is cleaner and easier...
... If one pull request. That said, we'll have added examples.

Gower: Is it ok to put the war git targets in as url's for now so that it's all functioning? Or do you want the links broken? I found it easy to have raw git targets.

<alastairc> Yes, please do include the rawgit links as part of the PR, we know they'll change later.

AWK: Michael what do you think?

<alastairc> WAit, in the PR desc, or in the files themslves?

MC: You should put in raw git links so people can review them, and it's my job to figure out what to do with them. I'll come up with doc or automation.

AlastairC: The question about inside the technique file...

MC: Asside from that we should probably use raw git links.

<gowerm> https://rawgit.com/w3c/wcag/tech-using-role-status/techniques/aria/aria-status-role.html

AWK: <sites a hypothetical example> ... but within that rendered version you have working example search results. Link to search results would be raw git link.

MC: That's all appropriate use of raw git. I'll be more motivated to come up with something more elegant.

Gower: Directory wasn't there when I did working examples. Should be able to put in relative links. Not sure we can count on the same directory structure.

MC: Use absolute URL's.
... Many things will change through the process. We may need to potentially rename examples.

Gower: I added in aria ... <fast talk> without it there was no context. Wasn't sure if that was...

MC: The generator I'm trying to write will pull in the context.

Gower: Do not number techniques, leave name, ...

MC: As long as they are in the same directory, don't add any meta data you don't have to.

Gower: If you can update guidance on technique that would be great.

AWK: In item are two precedures, expected procedure is that checks 1 and 2 are true.
... Last thing with this one would be whether we like the title.
... Does that work for people?

<AWK_> "Checks #1 and #2 are true"

Brooks: I like that term.

<AWK_> Using role=status to expose status messages?

Brooks: When you sayin in terms of AT not working as intended? I think "announce" is both audibly and programatically.

<Glenda> +1 add “status” before messages

AWK: One suggestion is adding status before messages. I don't care if it's surface or expose.

<kirkwood> make messages available?

<bruce_bailey> +1 to adding status to title

<alastairc> How about "Using role=status to provide status messages"

<JF> WFM

<bruce_bailey> Maybe present status messages?

AWK: Using role = "status".... reviewing many options.

<bruce_bailey> provide is good

<marcjohlic> expose works

AWK: No strong consensus. Gower can choose the word that works, any of the options seems ok.

<Glenda> expose

AWK: Any concerns about this? People on the call agree this is ready to go? Will go through regular wringer. Will share these through the list...

Glenda: Just looking back, why aren't we just saying "programatically available?" It's part of the SC. In the title of the technique.

<gowerm> Thanks for the feedback. That was really useful discussion!

<alastairc> MichaelG - I note the <title> of the page says WCAG 2.0?! perhaps update to match the H1

Glenda: All these words, nowhere near "programatically available". Thanks for listening.

<AWK_> Using role=status to make status messages programmatically determinable

<Glenda> +1

<Brooks> +1

AWK: to make status messages be "programatically determinable"?

<bruce_bailey> -1, sorry

AWK: We risk making the title of the technique a repeat of the SC.
... ... it's the "live update". Maybe instead of... something about changes?

<bruce_bailey> I like the more plain language suggestions for technique title

Glenda: Joys of writing as a group.

<alastairc> +1 with bruce

Gower: I'll take a stab at it.

AWK: We should note that status message is a defined term.
... "Change in content that is not a change of context".
... We should link to the defined term in the description.

<bruce_bailey> thank you mike g

<Glenda> 2nd-ing what Brooks said earlier. Thanks to Mike for your work on this! This is hard to do. Deeply appreciate you helping this important technique move forward.

AWK: besides little quibbles, looking good. Any objection that this meets the 5 approvals threshold?

RESOLUTION: Pull request 431 has more than 5 approvals and will be decided next meeting.

Chuck: Learned something.

AWK: Hopefully we can have one example. Even one thing that appears easy can be hard.
... I had a few issues I wanted to raise that came up.
... Michael, 410...

https://github.com/w3c/wcag/issues/410

AWK: This is about a duplicate paragraph... I didn't see that in our previous erata list.

MC: I raised this new one.
... There is nothing in the master branch to edit. Only in publication branch.

AWK: OK. That's fine. There's a paragraph way at the top that's repeated.

MC: The lower down one is the correct one, the first one will be removed.

AWK: We can take care of that reduncy.

MC: Professional editorial

https://github.com/w3c/wcag/issues/324

AWK: Next issue, old one. 324. I commented on it. It's in understanding documents reflow, currently says "for people with low vision, large text..."
... <reads>

<AWK_> "For people with low vision, enlarged text with reflow is critical to enable reading. Enlargement enables the perception of characters and reflow enables tracking - following along lines of text, including getting from the end of one line to the beginning of the next line."

AWK: I proposed a change to that which was this (pasted in).

<AWK_> "For people with low vision, enlarged text with reflow is critical to enable reading. Enlargement enables the perception of characters and reflow enables tracking. Tracking is following along lines of text, including getting from the end of one line to the beginning of the next line."

AWK: Laura made the comment that this was not as readible from a grade level perspective. We can change it to make it easier. (pasted in)
... this is fairly simple change to the understanding documents. What do other people think?

AWK: I ran Laura's readibility test tool, but the change I just made makes it a grade level of 12 instead of 14.

Bruce: Now I can hear you.

AWK: readibility is back down to 12 with recent change. Jake made comment that sentences didn't work well.

<bruce_bailey> +1 for writing exactly what is critical (as AWK has done).

JF: One of the words making this difficult is "tracking". "Tracking" could be better defined? That's one of the words that makes this hard to parse.

<AWK_> For people with low vision, enlarged text with reflow is critical to enable reading. Enlargement enables the perception of characters and reflow enables the user to follow lines of text, including getting from the end of one line to the beginning of the next line."

<AllanJ> tracking is ... defined in the sentence

Glenda: I bet it's the accurate word to use. What tool did you use for readibility?

AWK: Webfx.com
... JF If I get rid of tracking ... that is actually a higher grade level.
... Not the word, the length of the last sentence.

Glenda: Tracking is following a long line of text. If you put a period there we are in good shape. That brings me down in Hemmingway to grade 8.
... I thought that most people reading this had a high school degree. Did you know that when our brains are under stress we are reading...
... 2-4 grade levels below your education.

<Glenda> "For people with low vision, enlarged text with reflow is critical to enable reading. Enlargement enables the perception of characters and reflow enables tracking. Tracking is following along lines of text. Tracking includes getting from the end of one line to the beginning of the next line."

AWK: OK. Don't know how much stock to put into these tools.
... <reads Glenda's pasted recommendation>
... Should we put "also" in there?

Glenda: Sure.
... That shows grade level of 9.

Gower: Challenge is we are using words different than intended. "enlargement". Why not use "enlarged text"?

Glenda: I like that.

<alastairc> Suggest: For people with low vision, enlarged text with reflow is critical to enable reading. Enlargement of text enables the perception of characters. Reflow enables following along lines of text and getting from the end of one line to the beginning of the next line.

Glenda: It's repetitive, but super clear.

Gower: <reading> that works too.

JF: Shorter sentence makes it more readible.

Glenda: Yes.

<Ryladog> +1

AWK: Should it say "reflow of text enables"?

Glenda: Down to grade 7!!!!!!

<Glenda> For people with low vision, enlarged text with reflow is critical to enable reading. Enlarged text enables the perception of characters. Reflow of text enables tracking. Tracking is following along lines of text. Tracking includes getting from the end of one line to the beginning of the next line.

AWK: "Facilitates" jumps us up to grade 14.

AlistairC: I do wonder about chasing grade levels. Short sentences... it's like putting full stop after every word makes it harder to follow.

<gowerm> For people with low vision, both enlarging and reflowing text is critical to reading.

Gower: Trying one thing.
... <reads alternative>

Bruce: I don't think "with reflow" is intuitive to people.

Gower: What I've got helps offer clarity.

<it's pasted in>

<Glenda> For people with low vision, both enlarging and reflowing text is critical to reading. Enlarged text enables the perception of characters. Reflow of text enables tracking. Tracking is following along lines of text. Tracking includes getting from the end of one line to the beginning of the next line.

AWK: reading

Gower: Taking another stab.

<bruce_bailey> I would rather see the tracking sentences as two sentences rather than three.

<gowerm> Reflow of text makes it easier for users to track from the end of one line to the beginning of the next line.

Brooks: Anybody ever think about... to me it's "critical to reading without interruption".

<alastairc> notes that reflow is explained above this sentence: https://www.w3.org/WAI/WCAG21/Understanding/reflow.html

<gowerm> For people with low vision, both enlarging and reflowing text is critical to reading. Enlarged text enables the perception of characters. Reflow of text makes it easier for users to track from the end of one line to the beginning of the next line.

AWK: There are so many different effects. I know from conversations with Wayne he's talked about headaches, exhausted, efficiency.
... I wonder if it's better to leave it...

Gower: Pasted shorter but accurate sumation.

<kirkwood> For people with low vision, both enlarging and reflowing text ARE critical to reading.

<bruce_bailey> +1

Gower: <Reads>

<JF> +1

AWK: you got rid of... part. Is that not part of what it should say?

Glenda: Is it critical?

JF: What's long, too long, long enough? Core requirement is that people can read it and understand it is more important than the length.
... One of the critical things about reflow is to eliminate horizontal and vertical scrolling. Retention drops when you have to scroll. Should we capture that somewhere?

AWK: I think that's in there.
... In next sentece/paragraph.

<alastairc> how about: Reflow of text makes it easier for users to read lines of text and go from one line to the beginning of the next line.

JF: does that not address your concern of the length of the sentence?

AWK: It was about part of the text that was saying "tracking was following..." that was the part that was taking out.

Gower: We don't need to explain tracking. We are using track as a verb.

AWK: I'm not sure that reflow does anything to help someone track something on one visible row of text. Should be more about following an entire sentence.

<bruce_bailey> +1 to deleting 2nd and 3rd sentences maybe.

Glenda: This particular item is about the pain of going from end of line 1 to beginning of line 2.

AWK: <reads>

<Glenda> +1 to gowers latest version

AWK: Mike's last version.

<alastairc> Wayne would say "enables"

AWK: We could say "easier".

Bruce: I don't think it's about easier. It's not parallel and it should be.

Bruce: You are trying to explain the criticality. You want to use the exact same frasing for both explanations.

AWK: In both cases we are talking about improvement.

Bruce: The whole point here is that reflow is as important as enlargement. I want them both to be the same. That's my strong suggestion.

<gowerm> Enlarging text makes it easier to perceive characters.

Bruce: We could work to make them more parallel.

Glenda: We are playing english teacher.

AWK: We've 4 minutes left, and one sentence.
... <reads>

<AWK_> "For people with low vision, both enlarging and reflowing text is critical to reading. Enlarging text makes it easier to perceive characters. Reflowing text makes it easier for users to track from the end of one line to the beginning of the next line."

Gower: Yes.

AWK: Bruce?

<bruce_bailey> +1

Bruce: I'm happy with that.

AlastairC: We may get pushback from low vision folk.

<bruce_bailey> agree that "makes it easier" is weak compared to "critical"

AlastairC: Happy with the formation, I would just go with... <various options>

Alastair: going with enabling

<Glenda> +1 “easier” it too week to match with “critical”

<Glenda> replace both “easier”s with “possible”

AWK: Let's put it out for comment as is. We'll ask low vision folk to review.

<bruce_bailey> +1 to glenda

<JF> +1 - word-smithing by committee is a drain on our time here

Glenda: "Easier" does not map to critical.

lot's of agreement.

<alastairc> +1 for possible

AWK: Any objection to using "possible"?

Bruce: Let's make both enables.

<kirkwood> enables

<gowerm> For people with low vision, both enlarging and reflowing text arecritical to reading. Enlarged text enables the perception of characters. Reflow of text enables users to track from the end of one line to the beginning of the next line.

<alastairc> WFM

<bruce_bailey> +1

<gowerm> For people with low vision, both enlarging and reflowing text are critical to reading. Enlarged text enables the perception of characters. Reflow of text enables users to track from the end of one line to the beginning of the next line.

Gower: Pasted suggestion.

AWK: I like "enables", but won't die on hill.

<Glenda> enable = to make possible (I’m good with “enables”)

<AWK_> trackbot, end meeting

- DRAFT -

Accessibility Guidelines Working Group Teleconference

07 Aug 2018

Attendees

Contents

Process discussion and feedback collection reminder https://lists.w3.org/Archives/Public/w3c-wai-gl/2018JulSep/0131.html

Silver review delay

Techniques needing work/review

https://github.com/w3c/wcag/issues/410

https://github.com/w3c/wcag/issues/324

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output