<Vicki> TMI
<shawn> scribe: Sharron
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?
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?
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
+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.
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
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]