Accessibility Education and Outreach Working Group (EOWG) Teleconference

07 Aug 2020


Shadi, Hidde, Shawn, Laura, Brent, Howard, Vicki, Daniel, Estella, Sharron, Sylvie
Sharron, Vicki


<Vicki> TMI

<shawn> scribe: Sharron

Personal pronouns in WAI Style Guide

Shawn: We had a thoughtful discussion last week about use of pronouns within personas and use cases. Since then I see that within the Understanding WCAG docs there are also use of pronouns.

<shawn> https://www.w3.org/WAI/EO/wiki/Style#Personal_pronouns

Shawn: so I have added similar wording to apply to other WAI documents. Letting you know that I brought this to the W3C Team meeting and it met with overwhelming approval.

<scribe> Scribe: Sharron

<hdv> +1!

Shawn: There are a few more steps and if approved it will apply W3C wide. I made clear that it was polished by EO. So if you can review the new language applied to other docs, and let me know what you think about it.

Shadi: I am not aware of other documents that use he/she pronouns.

Shawn: Yes, I found some instances in Understanding and elsewhere.

Shadi: I suggest the plural subject and pronoun is the smoother one and should come first.

<Vicki> +1

<brent> +1

<eoncins> +1 considering that documents are written in English

Shadi: Rewrite sentence with greater use of the active voice.

Shawn: OK, I've made those changes

Estella: I am not sure I understand the "use of active voice."

<shawn> https://www.w3.org/WAI/EO/wiki/Style#Active_voice

Shawn: In general the active voice is more engaging

Estella: It is easier to be gender neutral in passive voice.

Shawn: True

<shawn> https://www.w3.org/WAI/EO/wiki/Style#Personal_pronouns

RESOLUTION: To approve the wording of the pronoun section of the style guide.

Sharron: +1

<Howard> +1

<hdv> +1

<dmontalvo> +1

<shawn> +1

<eoncins> +1

<lkee> +1

<Vicki> +1

<shadi> +1+1

<brent> +1

<Sylvie> +1

Brent: If you come across other places where pronouns need attention, please do bring it to our attention.
... send email to the planning team and we can make the needed change to align with the style guide.

<Vicki> +1 Brent for no brainer fixes

Brent: I suggest that when/if we find something, we can make the change directly or suggest it in GitHub. The no-brainer fixes where the gender is not identified in the first place.

<eoncins> +1 to Brent and Shawn

<lkee> +1

<Vicki> +1

<Howard> +1

<hdv> +1

<Vicki> ha ha ha

Brent: Anything else around pronouns?

WCAG Support Materials Design

Hidde: I have worked on them a bit since we last met

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

<hdv> new documents: https://w3c.github.io/wai-wcag-supporting-documents-redesign/

Hidde: There is a new index page to take you to various designs. The idea was to make a design that is conssitent among COGA, Understanding, Techniaues, etc.
... I want one sentence one each to expalin what kind of doc it is. Even though content changes are out of scope, it seemed to make sense to provide a brief description to let people know what to expect.
... wanted to knwo what people think of that.

Shadi: It can work for Sufficnet Techniques perhaps but there are also Advisory Techniques and this description would not address that.

Hidde: Can we find a phrase that will apply to all of them. If wou want to knwo the difference you can use the defintitions in the Toolkit?

Sharron: +1 to finding that short clear phrase

Shadi: What is the benefit of having one phrase at the top, more info below, and an info box that further defines the differences?

Hidde: If we put the differences with such detail at the top, it could be discouraging.

Shadi: So could we not just use two short sentences at the the start and not have to repeat. One sentence to meet them all, then a jargony sentence below and then an info box.

<Zakim> shawn, you wanted to wonder if it's useful to distinguish and to give background on legalese

<shadi> [[Sufficient Techniques are ways of meeting WCAG Success Criteria]] and [[Advisory Techniques are good practices in accessibility]]

Shawn: Background is that the legalese there now was deliberately crafted to avoid the fact that countries were requiring the Techniques as a way to meet WCAG which was not the intnet. And it is improtant to know the differences between Sufficient, Advisory, and Failure.

Hidde: I understand that it was written with a lot of effort but also have gotten feedback from developers that they close the tab when they see it. Afraid that the doc will be like this throughout - unreadable and legalese.

Shawn: It will require broad approaval to change.

Hidde: I am hoping that we can summarize that there are several layers of Techniques without expanding right at the start, discouraging.

Daniel: A couple of questions - examples may not be the right word, can we find something more accurate? Also, the placement of the About this Page - it is at the bottom for screen readers, may need to move it up.

Hidde: Yes, can move to appear earlier

<Zakim> shawn, you wanted to say the About the Page has some info that should be at the top and some at the bottom

Shawn: I disagree to move it.
... some of the info here should be at the top, some at the bottom

Hidde: I would prefer to keep this as a very short section

Shawn: We may need to think more about how to organize the info, to make it shorter but move some of the info out of the About box.

Brent: I really like what you are trying to do here. My use pattern is to understand what is in the box and how to use it. It does not quite say that in the prototype does not convey the same information in terms of the fact that using this Technique specifically meets all three of these SCs. It does not do the same in the prototype.

Hidde: I did not see it that way.

Brent: It goes back to what Shadi said about the improtance of the differences.
... it does not seem clear how the distinction is made.

Hidde: Are there levels of Sufficiency?

Shadi: Suggest that you check with Michael Cooper about how these are mapped. Seems this section really is a mapping mechanism. There are several related requirements that may share techniques. Also want to underscore Shawn's comment about the importance of understanding the difference between these Techniques themselves and their separation from WCAG.
... I am wondering if, instead of trying to combine Techniques we may be adding complexity. Maybe use the Sufficient and Advisory distinction in the title of the Technique itself. Then you could use one brief sentence and remove it from the box on the right.
... So we would add the type of Technique at the very top as part of the title. Move the sentence from About box to above the title. And the main content would be that mapping.

Hidde: If we have the type in the title, using the page at all will require greater understanding of the WCAG hierarchies. I worry if we have too much jargon going around it will add complexity.

<Howard> +1 to Sharron's point

<shawn> Sharron: Seems by putting "sufficient and "Advisory in the name, would encourage people to understadn that. Just one time, and then you know for future. Seems simplifies.

<shawn> Sharron: It is an important distinction

Shadi: Could live with putting the type of technique on the side again. It is an important distinction to understand.

<Zakim> shawn, you wanted to say great similar - but now need more distinction - /me flinches and says maybe icons ? and to say yes, AG happy with change to that wording and to say "ABouit

Shawn: I fully support moving the Sufficient or Advisory to the beginning somehow and link it to an explanation. I also agree that AG will be happy for us to change and move the legalese we just need to understand and address the purpose.
... if you move the About this page box, some of it is related information to the content, not the page.
... I think this is brilliant to have a consistent design and wonder if now we need to make a distintion about which page is related to what topic. Icons maybe?

Hidde: I think icons could help reinforce that but would need a designer.

Shawn: The first time people land here, they may not know the distinctions but they absolutely NEED to know it. So we should be guiding them to understand those. And my eye does not even see th sub bar.

Hidde: That is OK in my opinion. We do not need them to understand the whole WCAG hierarchy in order to find the specific technique they need.
... like a grocery list. Just help them find the milk and eggs, don't make them understand how they were made and got to the grocery store.

<shawn> Sharron: You don't want people to think that an advisory technique is required. Or that it's the only way to do it. That's important.

<shawn> ... really like putting "Sufficient Technique" or "Advisory Technique" or "Failure"at the top. with an easy way to know what it means

Shadi: I agree with Sharron and Shawn. We are not requiring people to understand all the detail of how the hierarchy is made, but giving them the opportunity to differentiate between categories.
... I also like the idea of colors to reinforce that there are different categories to support the difference in Techniques.

Hidde: We do not have a broad palette

Shadi: May have enough to work with but I am not a designer.

<shawn> Sharron: Shawn's distinction between Techniques/Understanding and Supplemental Guideance

<shawn> ... also if sufficient, advisroy, failuyer - might run out of colors

<shawn> ... icons (dare I say)

<eoncins> +1 to Sharron for icons

Laura: We have to very careful with color +1 to Hidde
... There could be some distinctive visula formatting and some color may be OK but if it has other meaning elsewhere on the site, we really must be careful.

Hidde: You feel you are in WAI space with the blue so changing that is risky.

Laura: And I might also bump up the default font size

<shawn> +1 for increaing text size there

<Zakim> shadi, you wanted to speak about the moving side bar

<shawn> scribe: Vicki

Shadi: Side bar scrolling is a little annoying.

<shawn> -1 sticky for this box

Hidde: We followed ATAG. We can do a variation of this.

Shadi: I think the report tool is different. However, this is more static information so it doesn't seem necessary to have it in the same way here.

Hidde: I'll change it to non-stick

Vicki: -1 sticky

<shawn> s/1- sticky for this box/ /

Hidde: Any other comments on this topic?

<shawn> https://w3c.github.io/wai-wcag-supporting-documents-redesign/2020-07-15-prototype-understanding-quote-video.html

Hidde: The "Understanding" page, a little different. Alot more content. We have intent, benefits, examples, related techniques, key terms. I've removed the whole section of related techniques and replaced it with a link "how to meet..."
... Our ultimate plan is to have similar headers, design, aiming at consistency. The page should look a lot less cluttered. Any comments?

Brent: A first look: the same issue with the level, i.e., sufficient, advisory, failure. Here you are talking A, AA, AAA. I think it's important to keep a similar approach.

Hidde: I'll have to find a way to add this important information to the header.

Shadi: To echo Brent's comment, and to add to it, there is some clarity. It would be important to add "Success Criteria 243, level A: " and that would address Brent's comment to keep the information on the left, top.

<brent> +1 to Shadi. The "quoted" text doesn't come across as the actual success criterion language.

Shawn: I understand the aim for consistency but it might be necessary to be a little different. Just an idea: for the Understanding Docs, we will have the exact quotes from WCAG, so we may not need that title above. There are some little things different between the two and those subtle differences would be important to highlight.

Hidde: I'll play with these ideas and work on a revision.

Shadi: Back to your question, Hidde. You have removed the key terms, AG would need to have the final approval for that. There could be links to the terms in the glossary. I love the User Experience section. I'm wondering - now that we have removed a level - about the usefulness of the sidebar "About this page". Either level A will go to the left, understanding docs... I'm not sure if it adds anything.

Hidde: I think it's important to show you where you are, to help you if you have been on multiple such docs.

Shadi: I would usually look for that around the top.

Shawn: I think we had said this will have to be in every document in the main body.

Hidde: Will there be an overload in the main body. In the side bar, we take out some of the busyness in the main body.

Shawn: I personally have difficulty in processing information in columns.

Hidde: It just adds links to other areas. A kind of aide.

<Zakim> shawn, you wanted to say jump around and to say that one sentence from techniques near the top and to say page contents list? and to say hide

Shawn: Brainstorming...Just thinking about hiding the information.
... We will need to have one sentence in the main flow of each document. In answering your first question, Hidde, about jumping around... for me, my perspective, I want to know what the information on this page. Taking me off with the QuickRef, it would be annoying because I would have to jump to and fro between different resources. There is a lot of information on this page, but there are possibilities e.g. expand/collapse.

Hidde: It's possible, haven't done it here.

Shawn: I want to skim, I want to be able to focus on the part I need to focus on.

Hidde: I've moved away certain parts, e.g. key terms to allow focus on main area.

Shawn: I think key terms are an important part of the page. Maybe there tool tip, or pop up, would be able to cover this.

Hidde: Not sure how long the definitions are.
... Maybe we could have both, pop-overs or links. The main thing for me was to remove them from the main body of the page to avoid having such a long busy page. We just need to find a way around keeping everything in the main section.

<Sharron> +! to the idea that Key Terms is important to understanding

<Sharron> +1

<lkee> +1

<eoncins> +1

Brent: Thanks, Hidde... fantastic work on this. Having these prototypes let us see how everything is developing but it is so helpful to have the examples to look at so that we can comment.

<shadi> +1


Sharron: Thank you, Hidde. This is such great work. Thank you Brent for reminding us how much work is put into this. We think it is fantastic.

COGA "Content Usable" and integration in WCAG website

Shawn: When we working on WCAG, there were several things related to cognitive ability, mobile etc., that didn't fit there. So, the Task Force has come up with supplemental guidance. Might look like an understanding doc, technique, but the idea is that we use the same format. That was the plan a couple of years ago. We are now getting into implementing this idea. Currently, it is one TR document. Now that we are doing this, does the information i[CUT]
... COGA document, or does it fit better in the type of format that Hidde is working on. That is the big picture and question.

Sharron: What has been given to us in the COGA is way too long. It's difficult to understand due to the length. I think integrating this into general practice might be a better approach rather than the very long COGA document.

Laura: I did the survey. I read the COGA document. I love it. I think it should stay as a TR. I wouldn't say it is an OR, it is an end, ie. take the document, divide it into pieces that people will need. I even sent it to my team.

Sharron: I'm curious that you sent it to your team. ..

Laura: Well, it's because we don't think about this topic and this is a great resource to show how to integrate it into what you are working on. If they are given the information, and they take that responsibility, then, it's positive. So, whether it is in the long TR version or byte-sized piece, it makes sense.
... Everybody is still learning and now we are providing really great resources, avoid hiring a consultant to do a one day training which a team might forget.

Shawn: Thanks for sharing those perspectives. Sharron and Brett want us to consolidate input. Please complete the survey by Tuesday, August 11 so that we can discuss thereafter. If you need more time, please let us know ahead of time. Also, we have another survey closing on August 18. So, please, please let us know ahead of time if you need more time.

Shadi: Going back to Laura's feedback. I'm wondering what is the benefit of having COGA in a TR. If we have two versions, then, there is complexity in keeping both versions up to date. What is the benefit of having the TR?

<Zakim> shadi, you wanted to ask laura about the benefits of TR for her

Laura: Well, I'm quite new to this and I understand the work involved in maintaining 2 versions. If COGA was a TR does it hold more weight than if it was on the web site as a best practice? I like the idea of being supplemental but important. If it is just a best practice, would people ignore it because they don't have time?
... I liked that it was so comprehensive, that it was readable even though it was so long. I felt I could do something with it, if I wanted it. Each member of my team could take what they needed without having to read the whole document. I really liked being able to share that as a full document.

Sharron: Your feedback is important with you working with a team of developers.

Laura: I'm happy because we are giving our team the complete resource addressing many different aspects.

<shawn> ---- If you need more time on the surveys, let us know *now* (not just at the end)

Brent: Please don't forget to full out those surveys and if you cannot, then, please let us know sooner rather than later.

Shawn: Kevin and Mark on vacation and might need some more time.

Brent: Thanks so much to everyone

<Sharron> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. To approve the wording of the pronoun section of the style guide.
[End of minutes]

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

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/smother/smoother/
Succeeded: s/fizes/fixes/
Succeeded: s/Technaiues/Techniques/
Succeeded: s/discoraging/discouraging/
Succeeded: s/shoudl/should/
Succeeded: s/"Sufficient Technque" Advisory Technique "Failyre" /"Sufficient Technique" or "Advisory Technique" or "Failure"/
Succeeded: s/1- sticky for this box//
FAILED: s/1- sticky for this box/ /
Default Present: Shadi, Hidde, Shawn, Laura, Brent, Howard, Vicki, Daniel, Estella, Sharron, Sylvie
Present: Shadi Hidde Shawn Laura Brent Howard Vicki Daniel Estella Sharron Sylvie
Found Scribe: Sharron
Inferring ScribeNick: Sharron
Found Scribe: Sharron
Inferring ScribeNick: Sharron
Found Scribe: Vicki
Inferring ScribeNick: Vicki
Scribes: Sharron, Vicki
ScribeNicks: Sharron, Vicki

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 07 Aug 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]