Accessibility Education and Outreach Working Group (EOWG) Teleconference -- 09 Oct 2020

<shawn> scribenick: eoncins

<shawn> scribe: Estella

Topic 1. WCAG-EM Report Tool

<krisannekinney> present

Brent: Interest in looking on the interface. Shadi made a mock up he will present now.

Shadi: I share screen to make it easier. It has a WAI style but there ara a few components that have to be costumized. Near the top there is a menu with different buttons.
... the menu bar is a widget and afterwards is the navigation bar horizontal with five functions...

<brentb> Early draft of redesigned WCAG EM Report Tool: https://accessibilitynl.github.io/wcag-em-report-tool/svelte-preview/

Shadi: o fit it into the WAI webpage and and the ATAG report tool, we came up with the navigation bar across the bar. We took the same approach...
... the header is the same, some work is being made on the background. Same five steps and also the viewer report and we left out the menu bar...
... it will allow users to switch languages. We drop a link to key resources that can be found within the page. All links are already inside the guidance...
... you can start a new evaluation, open and save evaluation and go to view and download report in order to save it....
... there is a lot of bugs still, but we need to know if the drop of the menu is agreed. Please tay conceptual today and no focus on the bugs?
... are there questions/reactions/thoughts?

Kevin: It is great it is important the consistency. In this regards the language bar is important for instance. It might be useful to align this better.

Shadi: There are additional links that can be added.

Kevin: Consistency of translations is very important.

Shadi: Ideally we will have a lot of languages.
... Hidde it will be easy to skip to content and hide?

Hidde: In our tools there is a nice way to skip over.

Shadi: The text change and size it works we need to see if skip content it works.

<Zakim> Daniel, you wanted to ask about whether the WAI translation methodology is already available for translators

Daniel: I like this and for consistency I have a question: the language translation is available on WAI so it can be translated?

Shadi: What I know is that everything in in JSON files that can be translated. We don't actually have an easy way to translate resources. But it is not like translating WCAG.

<Zakim> hdv, you wanted to say translation in regular Jekyll site is different from these tools

Hidde: There is a difference in translating this resources and other resources because of JSON.

Brent: I love the simplification is a lot easier to stay in the tool with the menus and functionalities of the tool. In the current version new report and previous report is important...
... the only thing I question is the save. Will you be able to save at any time. Will you be able to save an htlm? Also if some paragraph has to be updated...
... I wonder if it is feasable and if it could be problematic when you are in the middle of a report and if you want to update any part.

Shadi: In the side bar rule you will be able to save.
... My question is does anybody miss the side bar?

<Zakim> hdv, you wanted to say: saving with ctrl+s is less useful than in JSON, because you can never import your 'ctrl+s''ed content

Hidde: If you export in JSON you can imported again, we have different ways of saving also in local.

Shadi: The control does save and will work on the new version.

Laura: I think you need a save button in all interfaces and if save and import are different you need also to inform.

Shadi: On every page there will be a save and an import button and it will also work on local...

<Zakim> shawn, you wanted to comment with multiple hats

Shadi: we are currently refining.

Shawn: I hate changes on interfaces. A lot of people are using the report tool. I think we have to be careful about making changes...
... I am for updating colours and this things but I miss the bar on the top with the arrows...
... this is only a visual element...
... let's see if anybody has another reaction.

<hdv> -1 to this comment, I think we need consistency and half-consistency would not be good in my view

Shadi: Transitions are always problematic. We could look at having an early anouncement.

Kevin: I agree with Shawn, changes are difficult and challenging but consistency is more important. A consistency approach is more valuable...

<Laura> +1 to Kevin's comments

Kevin: introducing it consistently is very important.

Shadi: We may also be able to get people excited.

<Zakim> kevin, you wanted to react to shawn

<Zakim> hdv, you wanted to say some feedback to ATAG Report Tool included people were looking forward to WCAG EM Report Tool to be updated in the same way (had 2 people, one active, one

Hidde: With the ATAG report tool comments that I received was that people were looking forward to changes and implementations.
... automatic saving and look and feel was more attractive.

Shadi: I love the progress bar as a signature of the tool. It took me a while not having the menu bar, but the side bar might be more effective for people who do not want the progress bar.

<Zakim> shawn, you wanted to ask about save

Daniel: I think consistency pays off and audiences of this resource will adapt easily to these changes.

<Zakim> Daniel, you wanted to agree with the changes here, they won't have a huge impact on functionality so I think the audience has enough bandwidth to get used to them

<Zakim> brentb, you wanted to say about change

Brent: I see Shawn's point on changes but I see what we are changing is the navigation piece of it but the content remains consistent...
... the changes make the tool more simplified to newcomers to this resource. The only thing is the adding of a button part on each page. Would this be problematic?

Shadi: It is going to behave like the ATAG report tool and there is no change of functionality only the UI.
... the expand and collapse is something that is being added. It is only fine tuning. I hope to have a more mature draft shortly...
... the aim is to unify with the WAI site.

<Zakim> shawn, you wanted to ask about save and to

Shawn: I have several issues, I like consistency but in the ATAG report tool you do not need sequence but in this tool it make sense to have sequences...
... the new design does not show that.

<Zakim> hdv, you wanted to say the redesign was done with WCAG EM in mind, respond to 'have to work in order'

Hidde: I do not agree that the ATAG report tool is different, functionalities are the same here. Interface elements from the old tool will not be effective because the main aim was to make this tool easier.

Shadi: Let's separate things. WCAG is sequence from 1-5 which does not apply to ATAG. But do we need the sequence and also the numbering which is an additional indicator? Do we want to do that?
... is there maybe a different way to indicate a progress which is also in the ATAG?

Shawn: I don't think it is need in the top, numbers are good indicators...
... remember that this is at the end of the reading order for some users.

Shadi: This is only a visual mimic, we could maybe find a compromise.
... We will have a side bar in any case and maybe we could add some arrows to indicate progress...
... so we don't break consistency.

Kevin: I disagree with this proposal about the steps 1-5, for me is more worth to know the progress on SC...
... when a work on an audit I work back and forward.

Shadi: Now we have an implicit showing indicator that we are losing in the new version...

should we put it in or leave it out?

Shawn: I don't see how arrows will replace the bar?

Laura: I don't see the need for a progress bar, if it is numbered the tabs work for me so I drop the arrows.

<Zakim> hdv, you wanted to mention skeuomorphic vs flat design

Shawn: One last point the save, is it different? For some of us that are used to the WCAG report tool is changing and now will be at the bottom...
... I just want to make sure that consistency is going to be kept.

Shadi: We are not going to change anything but you are right for some it will be on the top left and for others on the bottom.

<Zakim> shawn, you wanted to ask about save

Shadi: There are some benefits that have been included and I am not hearing any major problems. This is my understanding on the discussion. Thanks to all.

Topic 2: WCAG Support Materials Redesign

Brent: Hidde please jump in and go ahead. There is a link to the landing page

<brentb> draft WCAG 2 Guidance landing page: https://w3c.github.io/wai-wcag-supporting-documents-redesign/alt-index.html

Hidde: The first comment that I have addressed is about the side bar...
... for all of the different pages it can be used for understanding documents.
... my question is the box underneath the heading is good for you
... maybe need a different icoon?

Laura: I really like and stands out, people will read it and I am fine with the icon too.

Hidde: The icon is generic. Thanks.

<Zakim> shawn, you wanted to say first impressions: really like it! question: then maybe not have repetative in sidebar?

<MarkPalmer> +1 to the box

Shawn: I really like it, it reinforces the visual design. Do we want to have it in both pages?

Hidde: In the box only says sufficient, and in the sidebar it provides further information.

Shawn: If we have it at different places we may want it to be word the same...
... just think about that.

<Zakim> shawn, you wanted to say maybe exact wording

Kevin: The only question is that the * is the marker?

Hidde: We can also do it with other icons or maybe add the word "info"

Shawn: Will you have the same icon for all or a specific icon depending on sufficiency?

Kevin: I am happy to contribute to icons.

Laura: We do this all the time. We have information on the side.

Shawn: +1 to have shorter versions but it might be clear and consistent.

Laura: It looks like the title "sufficient if combined" is not much clear.

Topic. Create a “landing page” that lists all of the types of guidance.

Hidde: I have created a page with guidance between the WAI website and the documents...
... I would like to propose that this page is listed as guidance. We have sufficient techniques and other different types of documents...
... I am also thinking of putting a carrousels with examples of advisory techniques or sufficient techniques and other types of categories. Any thoughts?

Brent: How deep do you want to go into this? Or it is only about having a landing page?

Hidde: I would like to know if there is any problem in finding this types of documents and if this could be a possible solution.

Kevin: I think it is a good idea to tie things together with doubts on the carrousel.
... Could we group this and bring it to a real story. I know that this a difficult story.
... I mean to connected to screen reader users or other assistive technologies.

Shadi: It will be nice to connect techniques with real world stories but this is out of the scope.
... It is not about finding techniques but more about understanding techniques.

<Daniel> +1 to Brent's wording suggestion

Brent: What is the purpose of this page? If it is under WCAG2 Guidance a developer will understand that is about guidance which is not the purpose of the resource. If they are trying to solve the problem they will not get it here...
... to me the name of the document is wrong because the purpose of the page is to define the different type of guidence so the page should be calle WCAG 2 type of guidance.

<shawn> -1 for examples (I think?) they currerntly take too much attention in current design

<brentb> +1 to Shawn about examples

Shadi: To me the first two sentences enumarate the different types of guidance.

<JasonMcKee> i have another call so i need to jump but i want to thank you all for another great meeting and i hope everyone has a great weekend

Hidde: I understand what Brent is saying. It might be good to consider it.

Brent: I like the document it guides a developer to look for specific techniques. But the exemples might not work well.

Kevin: If this is guidance about WCAG2 or Type of Guidance about WCAG2 I am not sure about the aim of the page.

Shadi: This are suplemental guidance linked to WCAG2 and is dependent on them. The previous version is "The WCAG2 documents" maybe we need a clearer name...
... all these resources are linked to WCAG2.
... COGA is related to the guidelines not the SC maybe a tutorial might be also good.

Kevin: Is supporting documents a better title?

Hidde: We have to be careful when choosing a name that do not apply to all users.

<Zakim> shawn, you wanted to say how will this page do a better job than this existing page? https://www.w3.org/WAI/standards-guidelines/wcag/docs/ -- maybe just visbility from all

Shawn: Maybe using WCAG2 or How to use WCAG2? How would this new page do a better job than is doing. I am really for updating this page because we need a better more...
... just the people know what's there. For me your proposal is missing how to use it. You want to know what the pieces are and how to use them.

Hidde: For users that do not like to read a lot need to understand the different techniques and documents...
... people know that there are different documents but do not know the differences between the documents...
... it is tricky. I tried to be simplistic.

Shawn: My main point is that I strongly support replacing the current page with something better.
... Maybe there are 2 sections one about which are the documents and the second about how to use it.
... this page still doesn't explain very important aspects. Advisory means that we strongly advise but it might not apply.

Hidde: Do we want all the details in this page?

Shadi: Maybe there is something in between?

<Zakim> brentb, you wanted to say follow-up on shawn's simple sentences comment.

Brent: Back to Shawn's point on simple sentences. For me definitions are very important. I like simple sentence but I do not know if it can be successful...

<shawn> +1 to brent - and that info is in the (old ugly) diagram at the top of https://www.w3.org/WAI/standards-guidelines/wcag/docs/

Brent: explain them what they will find, provide an example and then link it to the pages

Hidde: A table of contents it might help.

Brent: I would also replace the old one.

Shadi: About the sentence descriptions need to be reviewed by the groups, the understanding documents also go beyond but I like the idea of a brief description and it appears on each of the pages but we should then check the consistency.
... I like the idea of 1 sentence description and a paragraph with a longer descriptions and a link to the page. I agree that revising this page is needed and also to make a link between the WAI website and the documents.

<brentb> +1 to Shadi's request of specific groups reviewing sentence description.

Shawn: Instead of paragraph I support bullet boxes...
... maybe a 1 line sentence and bullets. The current version it doesn't helping for developers or other users.

Hidde: Diagrams require a higher mental workload. It is quite difficult to understand between the different techniques.
... From a developer perspective there might be different ways to read a technique.

<shawn> "Advisory techniques are suggested ways to improve accessibility. They are often very helpful to some users, and may be the only way that some users can access some types of content." -- https://www.w3.org/TR/UNDERSTANDING-WCAG20/understanding-techniques.html

Shadi: We can start with 1-2 sentences and then work on that with the different WG.

Hidde: I have fears about interpretation and would like to be clear.

Brent: We can keep providing ideas Hidde. It is a good work.

Topic 3. TPAC

Shawn: We have the join meeting next week please register and let me know if you have questions.
... the link to register for the meeting is on the agenda.

https://www.w3.org/2002/09/wbs/35125/TPAC2020/

Brent: We have a survey going on please complete it. And also if you want to be part of ARIA let us know.
... Any other comments?

- DRAFT -

Accessibility Education and Outreach Working Group (EOWG) Teleconference

09 Oct 2020

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output