<scribe> Scribe: Sharron
Brent: EO Chairs met with COGA chairs yesterday to get in sync with their approach and why the TR format is important. Let's start with Laura's summary of feedback from her team member.
Laura: The LOC has created an
accessibility team and hired a lead. I sent the doc through the
channels and she provided feedback. I asked her how usable it
was for her. The organziatins? Most likely to use areas of
content? Can naything be removed?
... she did not exactly answer all the questions but did say
she uses WAI docs frequently, likes the QuickRef layout, misses
the side nav and ID'd some typos and other isues.
... noticed that scenarios are linked and other sections not.
Asked for more focus on actual frequent problems like popup
messages, etc.
... finally said she appreciated knowing about it and would use
it.
Shawn: Would encourage the
content comments to be submitted directly since it is out of
scope for EO.
... let's be sure to get through the open issues and then come
back to the items that need to be added to our feedback.
Brent: Please be patient since this is very last minutes, we may be jumping around a bit.
Shawn: Comment deadline for this is the 4th of September.
Brent: So let's take a look, we can look at the highlighted issues that need attnetion.
<shawn> Sharron: They feel strongly that they want to have a TR doc. Open to idea of shortening it.
<shawn> Sharron: They were not aware of where cognitive is covered in existing EOWG resources. They forgot we asked for their input on How People with Disabilities Use the Web and other resources.
<shawn> ... They asked if someone could serve a liaison
Shawn: Let's look at a couple of
open issues at the bottom of the doc.
... Vicki reviewed survey input and was unsure if we have a
common understanding of the recommendations for the User
Stories and personas. Leave as is or move to Appendix?
Brent: They spoke about how they
determined the order. Some of it was based on previous
feedback.
... last week we had some discussion about order.
Shawn: Unless we have strong feelings about moving section, we can leave no rec on that topic.
Kevin: In my mind, the User
Stories may be of interest to buisness analyst or someone
developing requirements. Not valuable to the content creator,
not really a key part or the best part of what this document
offers.
... the best most useful part is the Design Guide.
Shawn: But they have been advised
not to highlight or push that forward.
... we have as a possible suggestion to move the Mapping up in
the order.
... it is now mntioned in 4.x Appendix A as a topic of
consdieration.
Kevin: That gets away from the story of where are the User Stories if that becomes front and center.
Shawn: Maybe one idea is to make
our recommendation around that stronger? Take a look at that
section of our rec document and see if we are in
agreement?
... Do we want to suggest that they merge the summary and App A
so the objective description and icons would be in the Intro
and the table and all of it woulf be linked?
Kevin: Yes I think that begins to draw everything together and is a better intro to the topic.
<dmontalvo> +1 to that suggestion
Brent: I have a slightly
different approach, not being a developer myslef. As you go
through the intor you get the brief exposure of the Objectives
and then in the User Story the barriers are further explained -
an education piece. Then the personas and the design guide to
learn how to address them.
... so then looking at the App A tables, they go through the
Obj again and related stories. Finally it is a summary of
content that already exisits and has been presented.
Shawn: A real issue is the fact
that the document is so big, it needs a ToC and then a detailed
ToC. You never get a good overview of what it is and I have to
scroll 15 times just to get to the ToC.
... the point is that if App A was the Summary it would help
people grok what the doc is all about and get to the parts they
need.
Kevin: It also summarizes the issue, could use it as a way to dig into understanding and addressing the issue you are intereested in. It shows the realtionships, connections much more effectively than the linear view.
<shawn> +1 ! Kevin -- shows the relationship of all the information, which you cannot get linearly <<
Brent: That makes a lot of sense to me, I agree
Kevin: Here is the Objective and here is all you need to understand and meet that Objective. In a useful, actionable way.
Shawn: So are we prepared to make the strong recommendation that App A be merged into the summary?
Brent: It would mkae more sense to have the Introduction and then the Summary with the table.
Kevin: The Intro should be a bit rewritten and given that the table would be in the Summary, then the How to Use section can refer back to the Summary and how to use that and be more useful since the current How To Use section is not at all clear.
Brent: So that only works if we move the Intro above the Summary.
Kevin: So all these are dependent on the oter - move the App A to the Summary > move INtro above that > rewite How to Use
KrisAnne: I will embarrassingly
admit, I complete skipped the Summary and went right to How to
Use. Why is it called Summary since it is not summarizing it is
presenting the Objectives. Why is it not called
Objectives?
... While reading, I am wondering where are these Objective
defined?
<kevin> +1 to Summary = Objectives
KrisAnne: only found them when
scrolling. They are the Obj that the entire scheme is based on
and should be pointed to as what tehy are.
... can we combine them in a way that makes it easier to
understand the dependencies?
<brent> +1 to changing "Summary" to "Objectives and Mapping" as the summary section is not a summary of the document as a whole.
KrisAnne: if we move the App A - it is concise and easy to process - higher in the doc. Can we define the Objectives higher up as well?
Shawn: Call the section Objectives and Overview, List each objective as a heading, follwed by a decriptive defintion (as in the summary) and then the table from App A.
Brent: Are their multiple tables?
Kevin: Yes, one per objective
<Zakim> eoncins_, you wanted to ask if there is any established W3C guideline to structure TR documents
Estella: Is there a template for a TR document, what the names for the sections are supposed to be? Are they aligned?
Shawn: Yes the Abstract and Staus of document are required. Otherwise, mot sure...checking
Shawn: Are we OK with the comments made?
Brent: When I read through what
occured to me is the way the comment is worded - the clock is
actually a piechart and graph and that they look like a
clock?
... also #5 looks like crosshairs but to say "like a shotgun
pointed at me" is too much
Kevin: Could be disturbing for some people to look at a scope with crosshairs, something like that.
Shawn: Do most people know what scope and crosshairs are?
Brent: Otherwise the comments in the document seem OK
<Zakim> kevin, you wanted to suggest no icons
<eoncins_> I think it was icon shutterstock
Kevin: My suggestion would be to go as far as saying "don't use the icons" since they serve no real purpose. They don't serve as markers or connectors.
Shawn: It does say, use the icons more effectively to mark sections (if you find or create good ones)
Mark: I would be very much in favor of suggesting they omit the icons, they add nothing. You my be able to enhance it with embedded icons of higher qulity but don't lose anything by omitting them.
<kevin> +1
<eoncins_> +1
Brent: Unless they are used thoughout the document to establish realtionships or relevance of content to the Obj. But in order for that to be reasonable the icons must be improved.
Laura: I don't feel strongly one way or another.
Howard: Icons that match the concept, now most of them don't
Shawn: With the change to the structure, the User Stories, design Guide, and Personas can stay in teh same relative order.
Shawn: Most of us were already glazed over by the time we got here, not many comments. But the reading grade level is 15
Brent: So a recommendation is to simplify the language?
<Zakim> kevin, you wanted to say there is a lot of repetition and question how applicable this is some of the examples
Sharron: Is this not one of the sections that we thought could be better addressed other places? That it is not relelvant to the target audience as we understand it?
Kevin: I took an editorial pass. There is a lot of repitiion and a general lack of foucs.
<eoncins_> +1 to Kevin
Kevin: I don't know whether this is necessary in this sort of document. It uses an awful lot of words to say something obvous.
Laura: We did discuss removing it and linking to exisiting WAI resources.
Estella: I agree, it is actually a very confusing section. One of my doubts is because I don't see a linkto the other content and this section is not relelvant to the audience of the previous ones.
<shawn> https://www.w3.org/WAI/planning/org-policies/
Sharron: So the proposal could be to strengthen the policy statements around COGA issues in the existing docs and make a pointer
<Zakim> kevin, you wanted to suggest a shorter piece in How to use this document
Kevin: How to Use the document does not in fact do that. Maybe some of this content, much shorter and clearly stated could be used in that section. This document could be used to write policy, (as well as develop disign patterns, etc as relevent to each bit of content) How to use to build policy delivered in a punchier more direct way in that section would be more effective.
Shawn: Can you write a draft suggestion for them?
Kevin: Sure
<eoncins_> +1 to Kevin drafting a suggestion
Shawn: There were some things
left behind in the survey, who can do that?
... once we have that we can polish our summary and circulate
to EO to be sure we are OK with sending to COGA
Sharron: For the survey comments that did not make it into our summary doc, we can ask folks to submit direct GitHub issues.
<shawn> https://www.w3.org/WAI/content-images/wai-news/2019-12-03-w3cx-accessibility-intro.jpg
Shawn: Not sure when we started
them, maybe with the videos, here is the latest ones
... five icons, accepted them as good enough for the videos but
wanted to polish them up and use them elsewhere. So we have a
graphics intern and he has suggested these
Brent: shares screen with new versions
Group: Ear: Leave the old and
maybe just curve the bottom a bit more to emphasize the
lobe
... Eye - like the new one aye to the new eye
Shawn: Body - to use for one image for accessibility in general. that's the background
Kevin: I haven't seen it used that much, but seems a bit better than the stylized wheelchair for digital accessibility.
Sharron: I saw it used at W3C and Apple and we use it occasionally at Knowbiltiy for outreach
Kevin: OK, seems fine if you need only one.
Shawn: Yes the recommendation is that in general we will use the set of five
<shawn> https://www.w3.org/WAI/media/av/planning/#checklist
<shawn> rename physical icon , bigger brain, tweak old ear. new eye good.
Shawn: Will be sending the updated recommendation doc around, there will be curriculum items for those who want to review, and Shadi and Hidde will be back soon. So more to come in September.
Brent: Any other questions or announcements?
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/descritive/decriptive/ Succeeded: s/tempalte/template/ Succeeded: s/Document icons/4.x Summary icons/ Succeeded: s/ay/way/ Succeeded: s/Estells/Estella/ Succeeded: s/relelvant/relevent/ Succeeded: s/Leave/Ear: Leave/ Default Present: Sharron, Brent, Kevin, Mark, Daniel, Howard, Shawn, Estella, Laura Present: Sharron Brent Kevin Mark Daniel Howard Shawn Estella Laura Found Scribe: Sharron Inferring ScribeNick: Sharron Found Date: 28 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]