<Sharron> Scribe: Sharron
Brent: The team has processed feedback from GitHub and recent presentations. There are several open issues for discussion today. Denis will walk us through.
<brent> ARRM Project Page: https://www.w3.org/WAI/EO/wiki/ARRM_Project_-_Accessibility_Roles_and_Responsibilities_Mapping
Denis: Wanted to begin with
thanks for all the input. It has been months and there was a
lot of feedback. We reviewed and processed all of the comments.
Since the May presentation at AccessU have reviewed comments
again with a new perspective and to make the changes indicated
by the feedback and comments.
... as well we have a new TF member and that has helped with
the understanding of new perspectives. With the charter being
renewed, we want to have a shared vision for moving it to the
next level.
<dboudreau> https://github.com/w3c/wai-roles-responsibilities/issues
Shawn: Who is here today who has not yet seen or been involved in this document?
Denis: Helen, Kevin, have contributed. Daniel may be a bit new to it. Are you suggesting I need to do an overview?
Shawn: I wanted to check but it seems good, thanks Denis
Denis: Compiled all comments and feedback as GitHub issues.We tagged all the people who made the comments but I may not have done that right. If you have not gotten a comment response, let me know. We processed and closed 42 issues. If you are curious, you can review on the GitHub Repo. The one that remain opne are ones we need discussion for.
<brent> ARRM issue #37: https://github.com/w3c/wai-roles-responsibilities/issues/37
Denis: Let's start with issues
around voice and tone. There are three of them. Overarching
idea was that the tone is too familiar and not as
"authoritative" as WAI resources generally are. That was
deliberate, we wanted a sense of familiarity, peer discussion
rather than feeling that it is an authority dictating to
them.
... those comments were from Sharron and others. Jennifer and
Sean rewrote a lot of feedback from chairs and staff. So there
is a new version for your review. #43 was also to make the
document shorter, more concise.
... we tried to make it shorter but still have a difference
about the tone.
<shawn> Sharron: Didn't mean strong sense of authority. Approach is good. Informal is better. My feeling it went too far.
<shawn> ... Can become distracting. Also, my biggest push was for making it more concise, shorter. Knowing people hate to read.
Denis: We are so close to the document, if you can help with making it shorter, we welcome that.
<Zakim> shawn, you wanted to say EOWG recent approach
<Vicki_> I'd be glad to help Sharron take a shot at shortening it.
Shawn: Some of the things that we did especially with the redesign, we have shifted tone. For example the Busienss Case. EO is very open to that. Since the redesign, we have made a big push toward tersification. When we did the usability testing, we found that there was a strong preference for short text. In some cases however, like the user story narratives, their tolerance for more information
was high. Maybe take a look at what people really need to know in order to summarize.
scribe: People can have a short summary for those who just want to jump in and go with more narrative for those who need it.
<hdv> ATAG Report Tool: https://atag-report-tool.hdv.now.sh/
scribe: encourage yu to look at the ART for how short the intro text is with expand options for more info.
Denis: Yes, expand/collapse is a an option we are considering.
Vicki: I can take an edit pass as well.
Daniel: I did not read this in depth but when I took a pass for the survey, it was the use of subordinate phrses and things that made it hard for me to read. I don't think the stye or tone is an issue at all. But the complex sentences are difficult, plain language, especially for non-native speakers like me.
Denis: happy for you to point
those out. Anything that does not work from an
internationalization standpoint, we definetely want to know
about it.
... the goal is not to walk you through each issue that was
found but more of a higher level review. The 10 issues that
remain open - some are a couple of years old. Questions about
the intro we are not addressing since this is an internal page
only. We do need to update it, but we think we will put it to
bed for this charter and create a new version for the next
charter.
<dboudreau> https://www.w3.org/WAI/EO/wiki/ARRM_Project_-_Accessibility_Roles_and_Responsibilities_Mapping
<brent> me/ to Shawn, was that your queue question?
Denis: There is a need to revisit the goals and make sure they are aligned. We acknowledged the coments but did not afddress them since they are internal.
<brent> New version of Introduction page: https://www.w3.org/WAI/EO/wiki/ARRM_framework_introduction
Denis: There is a new version of
the intro and we could use an edit pass.
... next were issues of reordering items in the decision tree.
https://github.com/w3c/wai-roles-responsibilities/issues/47
<brent> Decision Tree page: https://www.w3.org/WAI/EO/wiki/Role-Based_Decision_Tree
Denis: Kris Anne brought up the
way that it was made before that UX and visual design were
separatd and should be closer together. We agreed but wanted to
move it further down in the consdieraton list.
... a lot of this feedback came from Kevin with a rating of
low, medium, high. Made it very easy to address and we
appreciated that.
... we came to understand that there was a discomfort with
business, project maangement were conflated. We wanted to
separate business strategy from analysis and managment roles.
We have tried to separate analysis from implementation and
management. As well to separate QA from development. Tried to
be clearer about specific roles and make a catch all for those
in procurement, etc.
... so these are longer pages but may be able to avoid "wall of
text" with accordians. The page is really just informational to
help people work through the decision tree. People often have
trouble finding their role in the big picture. So we try to
help with very specific defintiitons that fit into the bigger
picture.
<shawn> [ Shawn wonders if that part is clear in the Introduction? ]
Denis: meant to help people whose
actual title may be different than in the decision tree.
... Kevin also said that the primary role status was separate
from the decision tree and we ended up combining them. The
feedback has helped us simplify. There is information about
front-end developers that we think needs to be said and may
need it own page. Wanted to address that consdieration.
... by default, people seem to expect most responsibilities
fall into development but we found that nearly 70% of issues we
find during assessments come in the design phase.
Bill: The reason for this section
is the recurring characteristic that expects the developer to
have responsibility for nearly everything. We realized that
even though most things go through the developer in one way or
another, they often are not decision makers but are impleenting
based on design decisions.
... developers were assigned ownership often incorrectly and
this document tries to address that.
Denis: The tagging was not done correctly so you may not have gotten these messages on how these were addressed. To let you know now, we paid special attention to "ED-High"
<dboudreau> https://github.com/w3c/wai-roles-responsibilities/issues/47
Denis: We thought we may have a
different definition of "primary ownership" In our mind it is
not related to product ownership but the responsibility for
that aspect of project development. As well there may be a
disconnect about functional and nonfunctional
requirements.
... in our mind it is more about who is accountable in seeing
that the accessibility standard is met. Matrix - accountable,
contributing, or informed.
... We tried to be more granular than the product owner with
the accessibility features to allocate them into task
responsibilities. Wnated to bring this up in case people who
are contributing concepts is on the same page about what we
mean by ownership.
... we feel that we have reached another layer of maturity and
are ready to understand the next step. Should we tersify and
then do another review?
... or shall we review now? I have an ongoing discussion with
Helen as well about how agile development works within this
framework and we have asked her for input.
Helen: Description of the roles is more of how they work within a waterfall process. I can do an example of waterfall vs agile with QA that can illuminate the differences.
Denis: Do you think it will be a discussion of process or roles?
Helen: Probably some of both.
<Helen> +1 to wait until after the updates are done before the next review as work is ongoing
Denis: We can work offline. We did not feel we were emphasizing waterfall so much as linear in describing roles we welcome input on that.
<Jennifer> I too have to drop off at 9:30am EST. But thank you Denis for walking through this and to everyone for their comments ongoing feedback.
Denis: would ask people to look at the GitHub issues, add to them if they spark thoughts. Want to close the issues and complete the resource version within this charter. Then make the next version plan for the next charter period.
Brent: Continue to work through
the issues to resolution with whoever submitted. Can aslo ask
for review if issues are not specifc.
... may not need to revise the requirements for the new charter
period.
Denis: Great, thanks. Stephane and Lewis were contributing through the years and have had to drop. Want to acknowledge their contributions.
Shawn: Will do that in the acknowledgements page (can set it up now)
Sharron: Thanks, great to see the progress.
<shawn> +1 that most will use the default, and only some will build their own
Denis: Creating role based documents and encourage those of you who have those roles to help with that. We have built this in our cocoon and welcome the challenge from people who do these roles and have another perspective.
Shawn: Thanks all of you who got to the review but a couple of active participants were not able to get to the survey due to the short turn around. Wanted to be sure we had your approval.
Kevin: I can just register here that I am happy to publish.
Shawn: OK we wil get that in the survey.
Brent: Big announcement on Monday, celebration is required, thank you Hidde and Shadi for this really good work.
Shawn: And the Charter was approved and announced, it's done!
Brent: With the new charter, our name is officially the Accessibility Education and Outreach WG.
Brent: Shadi will talk to us about the updates coming for that.
<brent> WCAG EM Report Tool: https://www.w3.org/WAI/eval/report-tool/#!/
Shadi: Happy to see the success of the ART and looking at WCAG-EM report tool, we have this tool, originally made by Wilco. We have funding for developers to update it. Of the 72 issues, we have prioritized.
<brent> List of open issues showing prioritization: https://github.com/w3c/wcag-em-report-tool/issues
Shadi: P1 are those do not change
any features bur update the code base. Looking for conssitant
user experinces. Mostly bugs under the hood. "face-lifting"
toward the WAI site design.
... P2 are enhancements that do not really change the current
tool. Adding a button or filed but not changing the essential
functions.
... P3 are items and requests that add features (eg: a template
chooser or creator, etc.)
... those of you who have added feature requests can review to
see where your comments have landed. Or if you have not, this
is a chance to add to the issues. We will be working through
the list.
<brent> Just for information. Number of each type of issue... Priority 1 = 32 issues, Priority 2 = 14 issues, Priority 3 = 25 issues
Shadi: may be work for this week to review but open the floor for comment.
Sharron: How much is the tool used?
<shawn> [ Shawn notes that we have lots of good data on the WAI site overall, since the redesign. ]
<shawn> s/[ Shawn notes that we have lots of good data on the WAI site overall, since the redesign. ] / /
Shadi: We know that it is quite widely used by governments and government agencies. Companies have reported and taken the source code to make internal versions.
<eoncins> Agree with Shadi that in Europe is more a legal issue rather than being smart :)
Shadi: European Directive
requires monitoring and reporting and this has prompted higher
use in the EU perhaps.
... one of the issues is that the US focuses on VPATs,guidance
from the EC actually references the WCAG-EM Report Tool
directly.
<Zakim> brent, you wanted to say about priority
Brent: Appreciate the prioritization process, think it is a great idea. I might suggest that if there are any P2 or P3 issues that would have a big impact or that are widely requested that may be pushed higher because they are highly requested?
Shadi: We were cautious not to go
too far down rabbit holes that take a lot of time and
resources. We have chosen instead to start with the easy
issues, those that can be most efficiiantly addressed.
... finally it is up to the group. Any other overall questions
about the work, the plan, your role?
... Some P1s are stylistic, will look at the first 3 of
them.
... this was a comment from several years ago, the title is
clunky. One was can we rename it? Envious of the ART and trying
to think if there is still a need to consdier the title.
<Zakim> hdv, you wanted to ask about name change
<brent> WCAG is already an acronym. It's like wrapping an acronym inside an acronym.
<shadi> WeRT
Hidde: I like the compliment between ATAG Report Tool and WCAG Report Tool.
Helen: Since Web Content is removed from the title in the future, like the work of Silver, is that an issue.
Shadi: Is there a high enough discomfort with the title to work on a change?
Helen: Seems more likely to stick with it based on Hidde's comment?
Brent: Maybe just drop the
EM?
... I usually don't say ART, I use ATAG Report Tool when I
speak about it. I would also say out loud the WCAG Report
Tool
<Zakim> shawn, you wanted to say *if* we were to rename that tool, we should this, too. :-/ and to say acronym is not the issue I think
Shawn: I have found that too, we really do not need the acronym. The issue was Report Tool vs Report Generator.
<shadi> https://www.w3.org/WAI/planning/statements/generator/
Shadi: We had issue with the word
tool because it makes people think it may do the testing and
reporting automatically.
... we did use Generator with the Accessibility Statement
Generator Tool.
<Daniel> +1 to Kevin, he's just said what I was going to say
<eoncins> Also agree that "tool" is more user-friendly than "generator". "Generator" is very technological driven.
Kevin: The idea of simplicity is important. Tool is such a much easier word for the long term. The explanation of what it does is quickly made and we have a good short word for the long term.
<Vicki_> +1 to Kevin. Plus, it has been around for some time now. I would say leave it.
Sharron: +1 to stick with tool
<Zakim> shawn, you wanted to say that we propose to leave it, and close this issue
<Helen> +1 to keeping the tool
Shadi: OK, any objection or strong feeling to rename?
<Vicki_> Ship has sailed.
<Laura> +1 to leaving it as report tool
<eoncins> +1 to keep tool
<kevin> +1
Sharron: +1
<shawn> +1 to keep "tool"
<Vicki_> +1
<Mark> +1
<Daniel> +1 to tool
Shadi: Next issue may be moot since it is coming into WAI look and feel, does anyone have other thoughts about a logo or icon for this tool?
<brent> Agree, nothing needed if moving into WAI site branding wrapper.
<shawn> +1 to nothing needed now
<kevin> +1 to nothing needed now
<Vicki_> +1 to nothing needed
Sharron: +1 nothing needed
<Laura> +1 to not needed
<Helen> +1 to nothing needed
Shadi: Up next is the question of the WCAG-EM does actually apply to mobile. It uses the word screens and has other guidance on how to apply the EM to the mobile context.
<brent> Allow substitution for phrases "website" and "web pages" #348: https://github.com/w3c/wcag-em-report-tool/issues/348
Shadi: The idea was to take that into the Report Tool. I am not at this time aware of the tool being used in a mobile context so it may convelute the interface to solve a problem that does not exist. Thoughts?
Helen: I have not used the tool but I do use WCAG for mobile apps and sites. Until there are specifically guideliens for mobile, it seems it should be part of it.
Shadi: Maybe take a look at the
tool by Tuesday and see if it would fit the use you are
imagining.
... I will give you a small assignment, look at the spec,
browse through the tool and let me know if it would work in the
context of your work with mobile.
Brent: Jan and I were trying to use the tool when evaluating a one page web app. Same URL for each step of the app. So you are putting the same url and instead used a short descriptor. In that way, it did not lend itself to our purpose with the same ease of use as a page designated web site.
<Vicki_> ok
<shawn> scribe: Vicki
<scribe> scribe: Vicki
<Vicki_> Estella: Should be included from a European perspective, also important to include mobile apps
<Vicki_> Brent: I think this should be used to mobile apps, everything. I'm trying to say that it is difficult to use in that respect, if you change the words.
<Vicki_> Hidde: It is not a big issue to replace the word with something else.
<Vicki_> Shadi: I think we need to look at it more closely
<Vicki_> Kevin: The biggest challenge is how do we describe the terms
<Vicki_> Daniel: +1 to mobile, we can use other terms
<Vicki_> Shadi: Looks to me that there is quite some interest in this functionality. The team will look forward into this. Any input, thoughts will be helpful. If it gets too complicated, we might downgrade to Priority 2. We'll bring this back to EO. The renaming is moot.
<Vicki_> Shadi: Do drop any further input, ideas in github
<Vicki_> Shawn: Work for this week. Subscribe to the ?? (some odd mails come in), ATAG Report tool, WCAG-EM prioritization
<Vicki_> bye
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/ownershi/ownership/ Succeeded: s/defintin/definition/ Succeeded: s/fro review/for review/ Succeeded: s/acknowledgements page on publication./acknowledgements page (can set it up now)/ Succeeded: s/deault/default/ Succeeded: s/mush/much/ FAILED: s/[ Shawn notes that we have lots of good data on the WAI site overall, since the redesign. ] / / Succeeded: s/Accessibility Statement Generator/Accessibility Statement Generator Tool/ Succeeded: s/nothign/nothing/ Present: dboudreau Sharron shawn Daniel Vicki Helen Laura Kevin Mark Jenn Hidde Bill Shadi Brent Estella KrisAnne Regrets: Andrew Sylvie Jenn Greta Found Scribe: Sharron Inferring ScribeNick: Sharron Found Scribe: Vicki Found Scribe: Vicki Scribes: Sharron, Vicki Found Date: 26 Jun 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]