Accessibility Education and Outreach Working Group (EOWG) Teleconference

17 Jul 2020


Shawn, Kevin, Hidde, MitchellEvan, Laura, Brent, Shadi, Estella, Helen, Vicki, KrisAnne, Sharron, Howard
Daniel, Howard


<scribe> Chair: Sharron

<scribe> Chair: Brent

<scribe> Scribe: Sharron

UI Design of WCAG docs

Brent: Hidde worked on this, has done some proto-typing

Hidde: Sharing my screen to see the current techniques page. One observation was that there is a difficulty to identify you are on a WAI/W3C page, whether it is normative, and is hard to use. So I added WAI branding, title, link to all techniques to help understand this is part of a suite, link to all supporting docs that includes understanding and maybe some others.
... Then we have Description, Examples, and Tests. All other related stuff is moved to a sidebar and a statement of the required status.
... There are a couple of icons and I will introduce Tooltips to make things available (example - this is not required) but only if needed.
... Linked from the agenda, would appreciate hearing what first impressions are, what people think.

<hdv> original: https://www.w3.org/WAI/WCAG21/Techniques/html/H48

<hdv> redesigned: https://w3c.github.io/wai-wcag-supporting-documents-redesign/2020-07-15-prototype.html

Brent: Do you have a link to the old one to compare to this prototype?

Hidde: And notice that we have not changed any of the content - that is beyond scope.

Brent: OK so it is just structured differently

Hidde: Yes and the less important info is in a sidebar

Helen: Is the Tooltip accessible?

Hidde: Not built yet.

Helen: Will send a link to a support resource.

<mitch11> Typo: "Using ol, ul..." should be H48 not H46. (I know it's just for layout demo, but just to avoid confusion.)

Shadi: This is a first, rough prototype to show the direction we are moving in, no need to get to the detail. Are there other diections we should consider? Noted about the accessibility reuirement of the Tooltip

Kevin: This great - I love it! really slick and professional looking. The other one was impenetrable. Have you thought about in-page navigation?

Hidde: I am considering tabs

Kevin: Tabs always good, tricky to make accessible.
... what's the point of Previous and Next?

Hidde: Not sure it is useful, but for those who may study in sequence.

Kevin: I don't really see the point and have never used that. Maybe just a pattern accepted from the SCs, not sure it actually serves a user need.
... Is there scope to think about tagging to group logical relationships in techniques.Just an idea. The Suffienct, not required, I see as potentially controversial.

<Helen_> Maybe add "normative yes/no"?

Hidde: It is hard to explain but it is one of the things we identified in the requirements.

Kevin: I would expect a lot of discussion.

Hidde: Normative is a WCAG jargon that many will be familiar with.

<mitch11> I agree with every one of @Kevin's points, both the praise and the critique

Brent: Types of Techniques are Sufficient and Advisory. Failures are not a type. Is that right?

<shawn> [ visual description: Shawn, Shadi, and Kevin all shook heads back-and-forth "well, sorta" exactly the same in reaction to "Failures" ]

<brentb> Understanding Techniques: https://www.w3.org/TR/2014/NOTE-UNDERSTANDING-WCAG20-20140916/understanding-techniques.html#understanding-techniques

Shadi: Yes it is unclear if we will use only those two. Sufficient means it is sufficiant to meet the techniques, can't really be replaced with normative/non-normative. There are other suggested categories from COGA and Low Vision.

<Zakim> shadi, you wanted to ask about tabs and to respond to grouping of techniques and quickref tags

Brent: So Sufficient means this will satisfy the requirement; Advisory means it will be a suggested way to meet and maybe exceed the requirement; and a failure is something that will cause nonconformance.

<mitch11> Here are some words currently used in Understanding docs. 'Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.'

Shadi: Thanks for those observations Kevin. We are consdiering tabs, it would make things more compact but would not leave information in one place. What is the use case?
... As for related Techniaues, we do have a mapping that Eric did but not sure it is maintained. It is an interesting idea to use that mapping to build some cross references here.

<Zakim> shawn, you wanted to reply on prev-next (at top. and in-page links and to say -1 to tabs

Shawn: My perspective is not to use tabs, not a big deal. Could use an On This Page to link to sections in a visually simple way.

<kevin> Might be that there is need to develop a pattern for in page navigation within the new design system

Shawn: If you go back to the Previous and Next, I have never used them here but have often used them in the Understanding docs.

<shadi> +1 to Shawn on back/forth in *understanding* docs

Hidde: One thing that tabs can show is that there are three sections in the page.
... without scrolling

Kevin: If there is a pattern in the other resources for inpage nav, it would be good to re-use

Helen: I can see Shawn's point about that but I do like tabs. I agree with the need for a back and forth for consistency

Laura: I also prefer no tabs in this situation. I know we use tabs in place but here I prefer the inpage nav. The content is clean enough. I would prefer to scroll than click around. I like it though, Hidde - it looks really great.

Brent: The reasons for tab is to set information apart. So the question is how should the narrative flow? Are they related enough to be linear and scroll through. Or is the content discrete enough to need to be more clearly separated?

Hidde: Each section may have different audiences.

Shadi: I tend to scroll back and forth between sections to understand. Here I think the relationship between the 3 parts is strong enough to require its own tabs. The tests are being questioned by the AG.

<brentb> +1 to shadi. Relationship between Description and Examples is strong enough to be on the same page next to each other.

<Zakim> mitch, you wanted to say that back and forward belong in other docs, but not in Techniques

Mitch: Looking great overall. About the Previous and Next, the content here is arbitrarily numbered there is not a logical sequence so it does not seem to make sense to have the sequntial navigation here.

<shadi> +1 to mitch

<kevin> +1 to lack of logical sequence making prev/next redundant

<shawn> +1 to Mitch about Techniques not logical sequence (AND note that there *is* for Understanding)

<brentb> +1 to mitch

Mitch: I prefer not to have the content in tab format but I think it would be great to ask users who do not access the content often. Another way to use a techniaue in Wikipedia in mobile view, accordian behavior to expand or collapse sections.

<Zakim> shawn, you wanted to comment on scrolling and clicking

Vicki: I think it looks very nice, presentation is clean and clear. I don't think tabs are necessary but support the idea of user testing. Would recommend to follow design patterns from other pages.

Shawn: These sections almost always have a lot of content so use of tabs would require a more complex user interactions.

Laura: Shadi mentioned the relationship between the Examples and the Description is strong and so should maybe remain on the same simple page and leave the tabs out.

<krisannekinney> the layout is wonderful!

Hidde: The content is simple enough, usually able to easily scroll through, sounds like most prefer no tabs.

Helen: I like the layout, how is on mobile?

Hidde: Shows on screen, everything still linear with the sidebar info at the bottom.

Helen: There may be a use for it on the mobile.

<Vicki> How many users would need to see this mobile view.... Statistics of usage mobile vs desktop would be good

Shadi: Yes and I liked Mitch's example from Wikipedia with the expand, collapse

Hidde: It is funny to build but can do it if needed.

<mitch11> Remember desktop browser zoom users, too

Shadi: Vicki asks a good question, let's see about that

Hidde: Will take it to survey for EO and AG and try to make it easier to see what it will look like and add the Tooltip. I will come back with next iteration, thanks for the feedback, very useful.

Brent: So this is the prototype we will take to AG as well?

Hidde: Yes and if all agree I will clean up the code and go to next steps.

Brent: Any more questions before closing this discussion? If not, thaks Hidde.

Videos for WCAG

Brent: As you knw we have several video projects we have complete the Perspective videos, the Eval videos and we now have some others for consdieration.

<shadi> https://www.w3.org/WAI/EO/wiki/Video-Based_Resources

Shadi: When we launched the Perspective videos we were encouraged by the great receptions and commited to four addiitonal sets of video
... we completed the first set that introduces evaluation resources. We are on the second set, had planned to show off assitive technologies and how peoples access needs are different. set three is to bring the personas to life. For now we are explaining the 2.1/2.2 SCs briefly using people to demonstrate.

<shawn> https://www.w3.org/WAI/standards-guidelines/wcag/new-in-21/#guideline-13-adaptable

<shadi> https://www.w3.org/WAI/standards-guidelines/wcag/new-in-21/

Shadi: the idea was to illustrate the intent of the SCs by using people experincing the barrier. Rather than read the text, users could see the barrier in place. Create a scene of a real person for about 30 or 40 seconds to show the issue.
... For all the 2.0 SCs we have proposed to create scenarios like the ones in the text based people oriented scenarios created for 2.1.
... then we will film all of them. The concern is that this is not sufficiently engaging to be useful.

<Zakim> shawn, you wanted to comment that User Experience is planned to be added to each Understanding doc -- e.g.,

Shadi: they will not be as long as the Perspectives video, does each SC provide enough to make a compelling video?

Shawn: We had planned to put quotes from people experiencing barriers into the Understanding docs.

Shadi: These quotes, while they are a separate issue, would be related and match the scenario in the quote. Both would end up in the redesigned Understanding
... there are obviously difference in the content of each SC that makes better video than others

<Zakim> eoncins, you wanted to ask about the accessibility of the videos resources

Estella: None of the WAI videos use sign language and yet it is in the Guidelines - wondering why it is not used and available?

Shadi: That may be a slightly separate discussion, we would have one that highlights sign language but not for all of them.

<shawn> [ Shawn also notes that there are multiple sign languages even for English. ]

Estella: I understand the technical difficult of providing sign language but it is an issue within the deaf community for whm it is their native language. Wanted us to consider how we seem when we present a Guideline that we do not solve?

Shawn: There are so many different sign language vocabularies, we would need to provide so many versions, it is just not proactical. It is a AAA requirement and have not made it a requirement for ourselves.

Estella: Do you hear from the deaf community about this? I worry about it.

Shadi: Yes

<Helen_> Is it worth adding a note on the video about it is a AAA requirement and the W3C meet AA as a minimum?

Estella: In my group, we have some people who do provide international sign language to our medi resources. In Spain as well there are four different sign languages so I understand the difficulty.

<brentb> q later

Kevin: If this is all about the What's New in WCAG 2.1, the quotes present the negative point of view - hre is how the bad thing impacts me. Not sure it reinformces the "Essential for Some, Useful for ALL" side of things.
... some are focused on mobile, would it be useful to fous on that?

Shadi: We are looking at all of the SCs and with the coming of 2.2 we look at 82 SCs

<Zakim> shawn, you wanted to reply to Kevin and to say not just new 2.1, but *all* and to say 81ish videos

Kevin: Some are straightforward but some have so many repercussions - like relationships - not sure it would be easy to pack into a 30 second video.

<mitch11> +q to comment on redundancy of 'works well' examples and how to avoid redundancy

Shadi: So to be sure that we understand that we do mean to make tutorials for each one, simply a quick way to understand what the point of the SC actually is. So for something like 1.3.1 we would not try to explain all the ramifications but just to highlight what it means.

<mitch11> I meant mainly in the context of videos, and not just the 2.1 new ones

Helen: 81 videos could scare people and make it seem so overwhleming. But a grouping as Kevin suggested of the Mobile related, etc could be useful and less intimidating. Are you intending to clarify when SCs change levels - from AA to A for example?

Shadi: No intention to do that, just an illustration of what ti means and how it impacts users,

Helen: But what about conflicts when Scs are changed?

Shadi: In these 30 seconds we are jsut illustrating.

Helen: From a user perspective?

Shadi: Yes to keep people from the shock of the wall of text, just to show impact. Not a business case to show the value of accessiiblity overll but rather something to ease people into understanding what the SC is addressing and what it means.

Helen: So will it have - this is the barrier as well as this is the outcome when you do it right?

Shadi: Yes

Brent: To me as a manager at Pearson, these would be extremely useful. It will help my developers understand why you need to do it. They will see the problem.
... it is not at all uncommon for developers to ask :what is a screen reader/" So to me, having a video that shows the block that occurs and the ease of use when the barrier is removed, it will take so much less time for them to understand. This is of huge value in my mind.

<Zakim> mitch, you wanted to comment on redundancy of 'works well' examples and how to avoid redundancy

Mitch: Really well said Brent. I think that for the most part the SCs are distinct from each other but there are some that are so closely related that there is a risk of redundancy in the 'works well' parts such as keyboard working well. Need to be conscious of using different devices and user scenarios.

Shadi: Great input, but let me be sure I understand. Are you suggesting we combine issues into a theme or to be sure we keep each SC separate?

Laura: I was going to say I did not think it useful to have a video for each one, but I am persuaded by Brent. Still think we maight want to consider combining some of them.

<shawn> +1 to Laura not have to have a video each SC

<kevin> +1 to Laura’s comment

Shadi: Yes we have considered that for some of them.


<Zakim> shawn, you wanted to say Shadi's comment made me think about maybe for https://www.w3.org/WAI/fundamentals/accessibility-principles/?!? instead. also, to break her silence ;-) and

Shawn: When Brent let us know tht so many developers dont understand how AT works and Shadi said peopel are put off by the wall of text. Wonder about videos to help them understand the Principle of Accessibility. We have planned videos on the stories of web users, but I am afraid these SC planned videos may not meet your goal, Brent.
... I am thinking that for most of these a video will not help. The redesign of the Technaiues is good and when I think of putting a video in the mix I think for some of them it wouold be very useful but others not so much.
... maybe think about for which of them might videos be useful and where might our video resources be put to better use?

Estella: The users of these videos then are meant to be techies?

Shadi: Yes and could also be thier project lead.

<shawn> [ I think audience is *anyone* who wants to understand the SC -- could be designer, developer, manager, etc. ]

<shadi> +1 to shawn

Estella: It is very important to take this into account. As it is now, the text heavy resources make them bored. A mapping of each would be helpful I miss the raising awareness issues for people like procurement officers and may want to keep that audience in mind as well.
... we risk losing focus if we do not keep the audience clear.

Shadi: My personal audience is those who go to WCAG. Not meant for the video to be all the detail of the SC but to understand why it is a problem and then are ready to dive into the text.

<Zakim> kevin, you wanted to ask if there is a risk of only seeing the one part of an SC shown in the video

<mitch11> I agree with Shadi's last comment. Audience of the videos is same as audience of WCAG, quite broad. Earlier @shadi said it's an alternative way of gaining understanding of the same information.

Kevin: I worry that people will say "OK, I saw the video, I get it now" So there is a risk of lack of detail, being assured they understand more than they do. I like Shawn's suggestion for doing this in a targeted way.

<mitch11> I think of it like decorative iconography which reinforces text

<Vicki> Brent swayed me too. I think a combination would be good in order to reduce the number of videos.

Shadi: I heard the suggestion of the Principles and a thematic approach

<shawn> https://www.w3.org/WAI/fundamentals/accessibility-principles/

<kevin> s/

Shadi: These are a paraphrasing summary of the Guidelines. Solution A is to make a video of the Principles and selected SCs in addition.

<Vicki> Ok, sold on that Shadi. Option A. i.e. video on Guideline Principle level and illustrate selected criteria.

Shadi: This is the idea that we want a higher level of approach. Option B is to abandon this idea altogher and use the resources where it will be more useful.

Howard: The one advantage of doing it for each SC, you would have consistancy of having one on each Understanding page as they work specificlly with that resource.

Shawn: The idea of illustrating the Guidelines was worth exploring. I had not thought of Kevin's point that people may think I saw the 30 seconds and now I get it.

<kevin> +1 to keep barking up this tree

Shadi: Does anyone think this is barking up the wrong tree altogether and we should use the resources elsewhere?

<mitch11> Another possibility: provide a static image (or sometimes more than one) in every success criterion, and a video in some

Helen: It seems it will help people to understand how it impacts people and thier experience of trying to use inaccessible resources.

Shadi: And we are working on the videos to support How PWDUW.

Laura: I agree that a video may make the text more understandable. I also in my own experience have seen that when we have a demo, developers get it. My collegue is blind coder and can expalin in a way that makes it acceptable. I do *not* think we are barkign up the wrng tree.

Brent: I completely agree that when we bring our disabled collegues to meeting with developer it makes the difference. A day at the School for the Blind helps them turn the corner and get on board.
... seeing it demonstrated is huge.

Shadi: One of the things that occured to me is how many of these could be diversified. Screen readers tend to come to the front of the stage but there is room for diversity in how we provide examples from different kinds of disabilities. We can send quite a powerful meesage.

<krisannekinney> same here!

<kevin> Agreed

Laura: I totally agree that many understand accessiiblty to be only about screen readers. This could be a great diversification tool.

<eoncins> Agree

Shadi: OK thanks for the inpu, I will approach starting with the Principles and then start deciding which SCs we want quotes and/or videos for and sketching scripts for them. Those are my conclusions for the discussion - thanks.


Brent: PLease visit the Work for this week, comment on the interface development; outreach is next...Shawn

<Zakim> shawn, you wanted to comment on outreach for "workshop" next week

Shawn: This is an unprecedented opportunity to hear from all way staff - 9 of us will present in a forum hosted by Knowbility.

Laura: I sent it around to federal government sources.

<brentb> Sharron: I want to officially thank WAI staff for willingness to present the forum.

Brent: thank you for that Laura

trackbot, end meeting

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/07/17 14:33:01 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision of Date 
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/failiar/familiar/
Succeeded: s/Thansk/Thanks/
Succeeded: s/informaiton/information/
Succeeded: s/thought/though/
Succeeded: s/questions/questioned/
Succeeded: s/since/sense/
Succeeded: s/sequent/sequence/
Succeeded: s/who do access the content often/who do not access the content often/
Succeeded: s/to Mitch/to Mitch about Techniques not logical sequence (AND note that there *is* for Understanding)/
Succeeded: s/desktop zoom/desktop browser zoom/
Succeeded: s/breifly/briefly/
Succeeded: s/wll/wall/
Succeeded: s/there is a risk of redundancy/there is a risk of redundancy in the 'works well' parts such as keyboard working well/
Succeeded: s/consdiered/considered/
FAILED: s/consdiered/considered/
Succeeded: s/soing/doing/
WARNING: Bad s/// command: s/
Succeeded: s/thematice/thematic/
Succeeded: s/Sooption/Solution/
Succeeded: s/which ones/which SCs/
Default Present: Shawn, Kevin, Hidde, MitchellEvan, Laura, Brent, Shadi, Estella, Helen, Vicki, KrisAnne, Sharron, Howard
Present: Shawn Kevin Hidde MitchellEvan Laura Brent Shadi Estella Helen Vicki KrisAnne Sharron Howard
Regrets: Daniel Howard
Found Scribe: Sharron
Inferring ScribeNick: Sharron
Found Date: 17 Jul 2020
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]