Video Scripts

Shadi: Thanks to all who commented, approving the changes but there were a few more comments. So now we may want to look at the subsequent tweaks.
... can look at the suggested changes, none to visuals or sequence, mostly text tweaks for clarity. Would like to run them past the group since we won't have another survey.
... Kevin points out that we use the word 'vendor,' especially sequence 4 in video 2. Kevin thinks the term may be too US-centric and suggests "supplier" instead. Any comments, objections, or issues?

Mark: Certainly in my experience, supplier is the more common term used here.

<HelenB> +q

Kevin: I am not 100% on that but did a quick check of those around me and it is just a bit jarring.

Shadi: Yes, thanks for the clarification, others?

<Laura_> +1 to helen's comments

Helen: Suppliers seem to me to be people who provide food and such while vendors is more associated with software.

Brent: Informally we tend to use vendor but in contract language we use supplier. Somewhat interchangable but officially we do use supplier in my business.

Kevin: My own experince tends toward supplier in business use but I am happy either way.

<shawn> [ me has no strong opinion ... does note "supply-chain management" is a thing ]

Lewis: Looking for definitions, found key difference.com Vendor is one who supplies goods directly to a customer, supplier one who sells to a business.

Shadi: I am hearing a bit of a lean toward suppliers.

<shawn> vendor/supplier

Laura: In 15 years working in the LOC, and many people from different cultures, I have never heard the word suppliers, we always say vendors.

Eric: I think it is more a matter of preference

<Hidde> I have no objections to 'supplier' (or 'vendor' )

<HelenB> no objections to either as interchangeable

<markpalmer> No objection

Shadi: Seems the lean is toward supplier, I think either way we will jolt someone, so if we flip the coin to the side of supplier, does anyone object?

<shawn> I'm fine with either word

<Lewis> no objections to suppliers

Brent: Vendors to buy from but suppliers to work with

Shadi: Laura had the strongest feeling against suppliers, are you OK with this decision?

Laura: Yes, no problem.

Shadi: OK thanks, other things to run past the group. Later, in Sequence 6, we are talking about Easy Checks, saying it is not a complete evaluation. From the heading people get the idea that it is more easy than it turns out to be not so short, not so easy. Wanted to make it clear that even just a few of them may be useful.

<Lewis> I think that "even only" is awkward. Better to use even or only, but not both.

Shadi: [reads from script] this is trying to crystallize that even doing just a subpart of the EC can give an indication of accessibility status. Is this re-wording any better?

Lewis: It just reads badly - maybe "even some"

Laura: I agree and suggest "doing even only some" is a mouthful. How about "just a few" as an alternative.

<shawn> [ /me brainstorming: Sometimes doing only a few of these checks can give you an indication of the overall accessibility. }

... should not use both the words together.

<kevin> +1 to Shawn and Laura's joint suggestion

<yatil> +1 to Laura

<Lewis> +1 to just a few

<Brent> +1 to just a few

Shawn: I had typed something similar "only a few"
... happy to go with "just a few"

Helen: Why is it EasyChecks?

Shawn: Great question, huge issue and we will address it when we revise the resource.

Shadi: Are we thinking of changing the title?

Shawn: No, but may tweak content to put really easy ones first, and others clearly secondary

Shadi: So suggestion is to omit "even only" replace with "just a few" With that change, any other thoughts?

<shawn> current: Tools can be integrated into different work environments. For example, into your web browser, content management system (C-M-S), and your development and deployment tools.

Shadi: Moving on to Video#3, sequence #7 there is a suggestion to smooth the text [reads from suggested text]
... any reactions?

<hdv> +1

Eric: Yes it's good

<yatil> +1 because basically my initial suggestion :-D

<shawn> "

<shawn> Yet be aware that tools can, in some cases, provide inaccurate results too.

<shawn> So avoid relying too much on what tools say over addressing the real-life experience of website users.

Shadi: OK thanks and moving down in the same script, seq #9 and #10 have been edited [reads text] addressing several comments received on these 2 sequences. Reactions?

Kevin: This may be minor, addressing the multiple use of the word 'too' in sequnce 9.

<shawn> Suggest: "Yet be aware that tools can provide inaccurate results in some cases."

Shawn: Simplyfying sentence structure and doing what Kevin said

Shadi: Thanks for the suggestions, I will play around with them and making sure we are in agreement with message.

Eric: For me when I hear "be aware" it sets off alarm bells. That may be OK in this context but wanted to point it out.

Shadi: Is it not OK to set off the alarm bells?

<shawn> "Note that in some cases tools can provide inaccurate results." ?

Eric: Maybe but we should know that people may look at that and then think "it doesn't work all the time, will not do it at all"

<HelenB> https://accessibility.blog.gov.uk/2017/02/24/what-we-found-when-we-tested-tools-on-the-worlds-least-accessible-webpage/

Shadi: We emphasize so much the positive, I think a note of caution may be useful. People want their green check marks.

Helen: What about the fact of the percentage of items that can be reliably checked? The items tend to be easy checks that a tool can find.

Shadi: That refers to coverage, which we have mentioned but this is also a pointer to the fact that some of the results themselves my be inaccurate.

Helen: Yes, false positives or negatives. How about rather than "be aware" we say "It is recommended that results be manually verified." or
... "automated results require manual varification."

Shadi: But it is beyond that, even the semi-automated checks may be buggy.
... Eric is saying the "be aware" needs toning down and it seems you agree.

Helen: Yes

Kevin: The chances we discourage people from using automated tools due to this sentence is neglible. I see no problem for saying "these things are unreliable and should not be used as a final way to determine conformance"

<shawn> +1 to Kevin

<shawn> "Note that in some cases tools can provide inaccurate results." ?

<HelenB> +1 to Sawn

<markpalmer> I'd rather they used automated tools over doing nothing so long as we don't encourage them to use automated tools only.

<kevin> +1 to Shawn

<Laura_> +1

<yatil> +1

<Lewis> +1

<hdv> +1

Shadi: OK thanks, those are what I needed to run past you. Next steps are to send the first video for a rough animation with a rough reading over (not the voice pro,music, or sound effect) Please allocate time to watch the short video and have your ideas ready for discussion. Will have a follow-up survey.

<HelenB> +1 to video 1

<yatil> +1 to video 1

Shadi: Thinking that it will likely be video 1 as the first 'mock-up'
... any objections to that being the first?

<shawn> [ me *mildy* votes for video 5 then video 1 -- totally happy to do 1 first ]

Brent: Maybe video 5 as a first one?

<Brent> No preference, up to editor and production company

<yatil> [ Great Work, Shadi! ]

Brent: any other comments?

Review pages and levels

<shawn> https://www.w3.org/WAI/EO/wiki/EOWG_Participation_Info#Review_Stages_and_Levels

Brent: We have names for the levels of review and Approval to Publish. We have tried to define them, spent F2F time tweaking names etc to set expecations and folks seem to still be confused. So we have added some mascots to each level hoping to clarify.
... We wanted to add a device that helps us all understand what level of review, animal handle names for each level. That way when you hear the name, you immediately know what level we need.
... providing a visual symbol to associate each level of review with an animal characteristic.
... [reviews each level and its associated animal icon]
... Our hope is that by saying the animal nickname, you will quickly understand the type of review it is. Are their any questions, does it make sense, is it an OK idea?

Hidde: I think the review stages are quite clear. Is there a nickname for the stage where requirements are being gathered?

Sharron: are you asking for an additional level to address gathering requirements? like a squirrel review?

Brent: Yes good point?

Eric: I do like the animals as a pnemonic but some of it is not quite clear to me. It is not linear, like going from the sky to the sea - is it necessary to worry about that?

Brent: It is more of a relation to the nature of the animal rather than linear progression from high to low.

Sharron: Based on our experience that some of the stages iterate in any case.

Kevin: It is brilliant, I like the relationship to how we work, just not sure about the dragonfly - how does it work with the actual task?

Brent: Yes, we struggled with this one, looking for a segmented creature to indicate that we were looking at just a section or sections, not the whole thing.

<shawn> also go from high-level eagle to tiny little detail that dragonfly sees

Shadi: The animal needs segments? - or is the point what it is doing?

Brent: Is everyone ok with dragonfly, if it is looking at that small segment of the flower rather than the big picture overview of the eagle?

Brent: Or are there any suggestions of animals that do something in segments?

<HelenB> caterpillar?

<HelenB> as would be similar to the butterfly

Brent: Thought that caterpillar changing to butterfly might cause confusion
... We can think a bit more about dragonfly either to switch out or change language. If you do have ideas or image ideas, please send them through to the chairs
... We would like to start using as soon as possible. If there are problems then we can iterate and improve.

HelenB: Is it worth having the iterative lifecycle in the animals to show how one stage leads to the other?

Brent: The worry is that that becomes much more complicated. The hope is that as people use it, it becomes really simple and obvious.

HelenB: What happens if request is for one type of review but then it evolves into something else? For example, if you end up doing some detail in an Eagle review

Brent: It is not extremely strict. However, if you are doing something from one review in another it might end up not making the cut.

Shawn: Also, from an editors perspective this can be distracting

Brent: Thanks, any additional ideas would be good before next Wednesday

Authoring Tools List

Hidde: There were some changes so the survey was slightly late. There are a number of issues that have been identified in the last few days.
... These have been prioritised for work.
... There are eight for discussion today

<shawn> monkey review!

<shawn> actually starfish review with wordsmithing

<shawn> put on GitHub or send to wai-eo-editors@w3.org

<Brent> Issues: https://github.com/w3c/wai-authoring-tools/issues?q=is%3Aissue+is%3Aopen+label%3A%22for+EOWG+discussion%22

Issue 52 Privacy Statement

<yatil> https://github.com/w3c/wai-authoring-tools/issues/52

Hidde: We are asking for personal information so we may need a privacy statement.
... Is there a policy on this?

Shadi: We can take this offline as it is a broader issue

Issue 50 Summary & Description

<hdv> https://github.com/w3c/wai-authoring-tools/issues/50

Hidde: Do we need a summary and a description. Summary would be displayed in the list.
... I wonder if we could have just the summary and people could find out more by visiting the vendors website.

Shawn: What is there now and what is the proposal?

Hidde: Currently there is no limit on the Summary field. The proposal is to have a character limit on the Summary field. A second proposal is to have a Description which is longer.

Shawn: So, Summary by default and then more info when details are shown.

Brent: This is what Kevin is proposing

<Brent> +1 to both fields

<Zakim> yatil, you wanted to say only one field

Shawn: My early reaction is that I like that, but might need more time to consider

Eric: Problem is that when you have both, people will use them differently. Some tools have good summary and poor descriptions and vice versa. Putting a limit in and have one field should be fine and would avoid this.

Shadi: I would prefer to limit free text as much as possible. The Evaluation Tools List vendors sometimes put in marketing information. I am not sure what any additional free text would be used for. I think we should be looking to direct people to the website of the tool rather than risk marketing information being on this list.

<shawn> +1 to character limit and +1 for decreasing marketeze!

<markpalmer> I'd be keen to limit as well. Focus the mind.

<markpalmer> +1

Brent: Agree with what is being said. Might there be a way to have a Summary or Description that only shows the first few lines. When you use 'read more' it would show the rest of the content. That might risk marketing content though.

Shadi: What would the extra description do?

Kevin: That's what I was thinking. That amount of info in that summary - not sure if you can get enough info about the tool in short character amount. appreciate the challenge of free text and needing to monitor marketing info

Shadi: Should I aim to ensure that the information we collect is consistent for each tool so that there is was to compare.

Shawn: It is quite hard to find basic descriptions of what companies or products do. I am leaning towards one field with a character limit. The submit form should also include guidelines on what information is being looked for to help the submitters.

Hidde: I like that suggestion as it helps the vendors provide the information we are looking for.

<shadi> +1 to limit!

Hidde: I like the limit on the Summary

<yatil> +1 to limited summary, -1 to description, not feeling too strongly

Hidde: Conclusion for now is to keep just the summary and limit the length.

<hdv> https://github.com/w3c/wai-authoring-tools/issues/41 text sizes

Issue 41 Text Sizes

Hidde: The text size varies between the main content and the other content. I was trying to use the size to convey importance of different content.
... This might need more design work thought.

Shawn: Might need to have time to have some specific feedback. Are you looking for a reaction to the different text size?

Hidde: Yes

Laura: I am ok for the different text size for the filter. The main content area will be the focus. I am comfortable with them being the same size though.

Shawn: Not necessarily looking for them to be the same size. Just for them to work better together.

<yatil> Looks good to me, nice hierarchy.

Shawn: The different sizes can cause discord if they don't match. I looked at Quick Tools and Evaluation Tools. I was surprised that the Eval Tools did use different sizes but they didn't jar. The design seemed to hold the different sizes together better.

<shadi> https://www.w3.org/WAI/WCAG21/quickref/

<shadi> https://www.w3.org/WAI/policies/

Shadi: I have limited design background, but comparing to Quickref, it has some different sizes. The list of laws and policies uses some variation. These are just points where other parts of the WAI site are doing it.

Eric: The laws and policies should all be the same size.
... We are not using size to convey hierarchy

Hidde: Do we not want hierarchy in the design?

Shadi: Paraphrasing Shawn, as a non-designer, there is no real visual separation between the filters and the content. When they are side by side the blocks are that well distinguished.

<Brent> The tools are in a white box. That is a slightly different background.

Hidde: I could look to address that with something that separates this out.

<hdv> https://github.com/w3c/wai-authoring-tools/issues/31

Issue 31 Remove "See full list of accessibility features" from every Details section

Hidde: The tool includes the accessibility features. It is helpful to include a link to a description of the features to explain them.
... This could be inside each tool entry, at the top of the page, in the filters. There are problems with each positioning.

Shawn: So is the question, should we have that link in every detailed spot or just at the top?

<shawn> Kevin: The difficulty I had, when was looking at the features, I was wondering "what does that mean".

<shawn> ... and wondered if I would want to be going back-and-forth between this list of features and the descriptions

Hidde: We are trying to help people to understand what accessibility in authoring tools is about. We know the concepts aren't common. It makes sense that you had these problems.

Eric: I don't know what the best way to do it is. The issue is that ATAG isn't as well known. One side thing that this tool could be doing is educating about ATAG. I feel that the descriptions should be as aligned as possible without overwhelming users.
... One idea is to have a side bar with, for example a Show Help button, to provide more information.

Hidde: If people have any ideas please do add them to the issue discussion.

Laura: I don't think the Full List link needs to be repeated in every tool details section. Maybe there is an option to make the link in the content at the top more visible.

Shawn: Had a similar thought to Eric. I think it will be common that people will need to explore the additional information on the features. I have found a couple of places where we have done this. I think this will be complicated but it will be a common use case.
... One idea is to have something like the show/hide additional info like that we find on the WCAG-EM Report Tool.

Hidde: I will look more at design options for this.

<hdv> https://github.com/w3c/wai-authoring-tools/issues/23

Brent: I would encourage everyone to explore the issues and add their thoughts and ideas. Also, it helps if you can indicate your strength of feeling about the issue.

Hidde: I have compiled a todo list based on the issues raised so far. Thanks to everyone for their feedback, it is really helpful.

Shawn: Hidde, would you call this ready for Starfish with some wordsmithing?

Hidde: Yes, I would like to get as many issues as possible so that I can address as soon as possible.

Brent: We will remind everyone of this when we send out the survey.

Outreach

Brent: Want to give a good month or two of attention immediately following the publication of new resources.
... The media resource page has ideas that others have done. This might give you some additional ideas.

Shawn: For this, internal links are great, but thinking about external links would be really good as well. This really helps SEO.
... Don't know how much SEO relies on social media but even that would be useful to build more interest.

Brent: If you have other ideas, please do reach out to Shawn

<shawn> Kevin: Accessibility Scotland event - invite you to re-tweet, will post videos online

<markpalmer> I'll also be absent next week due to Accessibility Scotland.

Eric: Just another conference to flag in Berlin, called Accessibility Club Summit https://accessibility-club.org/event/accessibility-club-summit-2019, in about a month. One day a barcamp and another day workshop. If you happen to be in Europe

Shadi: And Howard would remind us of Accessing High Ground in November as well

Work for this week

<shadi> [[and Accessibility Toronto next week]]

Brent: There is a survey on Face to Face meetings, please revisit that survey as we are considering a European meeting in June
... We will also have the 2-minute video for people to watch and comment on.
... Third topic will be authoring tools, please do review the issues and continue to provide feedback and ideas.
... Any other final topics?
... Thanks all