W3C

– Minutes –
Accessibility Education and Outreach Working Group (EOWG) Teleconference

11 February 2022

Attendees

Present
Brent, BrianE, Carlos, Daniel, JennC, Kris Anne, Laura, Leticia, MarkPalmer, Michele, Shadi, Sharron, Shawn, Stevelee
Regrets
-
Chair
Brent
Scribe
Sharron

Meeting minutes

Supplemental guidance

Brent: Trying to get consistent look and feel to the guidance pages. Turning to Shawn for an update.

<shawn9>UI Considerations: https:// github.com/w3c/wai-wcag-supporting-documents-redesign/wiki/UI-considerations#user-experience

Shawn: Please review the UI considerations in that wiki page, the information up to "WCAG Techniques and Understanding WCAG".

<shawn9> latest prototype : https://wai-wcag-supplemental.netlify.app/wcag-supplemental/patterns/o1p02-familiar-design/

<brent> done

<Sharron> done

<Laura> done

<JennC> Done

<shadi> done

Shawn: Any questions or comments?

Latest Prototype

Shawn: Looking for your reactions to the design prototype.

<brent> Latest prototype: https://wai-wcag-supplemental.netlify.app/wcag-supplemental/patterns/o1p02-familiar-design/

Shawn: The idea is to use the same design patterns as Understanding WCAG. It's the same content as last week.

Laura: First impression is that I like it. The menu on the right and the links are clear. It's very helpful.

Shawn: Hope this is the final design and looking to publish Phase 1 and do other tweaks after that.

Daniel: There is a region on the page called Content Pager. But I understand this will be fixed in the code.

Shadi:I like this, good to see it coming along. It took me a while to realize the "About" navigation in the top, that it's different from the main header. Also if Back to Top can be considered.

Shawn: It's not shown here, but it will be added. Currently a rough prototype.

Steve: Wondering if the menu items at the top (in the blue header, along with the rest of the header) could have a dark background so it stands out.

Shawn: Certainly we can look at improving the affordance of that. Question is: with About italic, and adding a yellow line between the links - is this enough?

Laura: I feel strongly because I totally missed the navigation links. So the dark blue bar would work. I'm not looking for navigation in the header, so I missed it. But the way we have the dark navigation background (like on the main WAI site) would be helpful.

Shawn: Agree to change visual design so links are apparent. This is a different navigation from the main site, so dark blue would be confusing. The COGA TF did also look at it in this way, with both set of links inside the light blue background area, and COGA comment was that the first navigation felt like a breadcrumb.

Carlos:I want to +100 what Laura said, I missed the menu when it was in the header. I like what you're currently showing, the two menus inside the light blue background. I was also assuming that menu is a breadcrumb. But even if you changed the design so it doesn't look like breadcrumbs, I still prefer the version with both menus in the light blue background.

<shadi> +1 to Carlos

Steve: Because this is a navigation, I prefer the menu to be designed similar to the main WAI site, but either way we need at least something to indicate it's a menu rather than part of the header.

Carlos: Have you considered the possibility that this small menu is aligned to the right inside the light blue background, rather than in the left (stacked above the other menu) to distinguish. But I realize it might not solve anything on a mobile screen.

Steve:I think there's still the issue of affordance.

Carlos: The other point to bring - similar to what Daniel mentioned, the label for the navigation bar. I notice that the up arrow isn't accessible to screen readers, so you just have the visual indicator, I know that will take me higher in the menu hierarchy. Also the previous and next arrows needs to be provided to screen readers.

Steve: I think there's some text we can use. Good point.

<dmontalvo> +1 to Carlos, I missed the hierarchy of that completely

Brent: For the left and right arrows, it says "previous" and "next" pattern, it's not needed.

Daniel:So the label for the arrows can be 'up' etc.

Shawn: For the About navigation to separate from the other nav, there is a separator line.

Steve: That looks better now. It's more like the separators on the right, similar, good.

Sharron: Yes, that looks better.

Shawn:Thoughts on the separator line between the two menus, inside the light blue background area?

Shadi:Definitely going in the right direction, from my perspective. I understand there's a lot of clean-up to be done, but the concept is good.

Sharron: I like the line

Carlos:So do I.

Laura: I like the underline style on the links on the About (smaller) menu.

Shawn: Would people be good with going with the separator line in the design as part of Phase 1?

<MarkPalmer> +1

<CarlosD> +1

<brent> +1

<Michele> +1

<shawn9> +1

<kevin> +1

<shadi> +1

<Sharron> +1

<JennC> +1

<Laura> +1

<BrianE> +1

<krisannekinney> +1

<Leticia> +1

<dmontalvo> +1 if we fix the missing arrows for sr

Shawn: Ok good. We will work and ensure we have all the designs and labels for screen readers in place. Thanks everyone.

Brent:Any other questions before the next topic?

Carlos: Yes, the list has left padding removed from the right-side menu looks better.

Shawn: Agreed.

Steve:Agreed.

Sharron:: Thank you both for all the hard work. The design makes it so much easier to read and understand, so much easier to use. Good work

Personalization

Brent: On the agenda we have links for you, talk about personalization and introduce Janina. There are a few links in the agenda - one is a background/overview of WAI personalization and work done by the Personalization group. Janina, I'll let you introduce yourself and the work.

Janina: Delighted to meet everyone. I'm one of the chairs in the W3C. We used to be known as protocols, and started ARIA, and you (EO) came up with the name, which is fabulous. We are here because Judy Brewer suggested that what we've been working on in the Personalization Semantics Task Force will be as powerful as ARIA. We need to increase uptake so are here in this conversation with EO.

Shawn: If you could explain the needs and goals for Personalization.

Janina: It's true - personalization can be many things. We are looking to build a specification technically for a webpage, the ability to hide or show elements. This was discussed in the COGA group. But we have a video demo - it allows relatively easy annotation of web content to support AAC. Alternative Augmented Communications - that is symbols. But AAC is different symbols for different regions/schools that you learned it from.

Janina:But the demo shows how we can personalize the symbols used in AAC. Some people communicated better than in words, and we facilitate that. To get access to the ones you know, rather than ones you don't know. This is one of the features for the demo to bring it to recommendation status. Another feature: helping you move to an area of a page. Generally, these are the things that we are building.This is just an overview, but looking forward to hearing questions about this. I'm happy to post in a link.

Sharron:This is a great introduction and I think EO will have to let things steep a bit before we can brainstorm the naming convention.

Janina:At TPAC we presented the demo and features, but there was a concern that this, as additional markup, where pronunciation matters, this could cause challenges - ie. if you're in a time-sensitive law exam, and you need it to work. But ARIA over time narrowed and narrowed, so it's just covering webpages - so we need to think carefully. The problem and question: overall, how do we make authoring easier?

Janina:The reason we ended up in a conversation about naming at all, we went to the COGA task force for feedback from the spec. The current winning name is Personalized Adaptation... Content Module. Something like that. This is why we are here, to discuss names.

Brent:To confirm, "Personalized Adaptation:" ... followed by the module name. Is there any feedback that we can gather today?

<shawn9> ---> idea on the table = Personalized Adaptation: Tools Module, Personalized Adaptation: Help and Support Module, Personalized Adaptation: Semantics Content Module

Shadi:One of the things I like about ARIA is that people use the acronym "ARIA" without really knowing what it stands for. Wondering if we can use something that is short and helpful. Like "PAd" for "Personalized Adaptation"

Shawn:If we go with an acronym, that would be the branding - and we could choose when to use the word "personalization"

Kevin: Off the top of my head and looking at what it is, it's not personalization but personalizable - it's allowing a content author to create or add meta data about their content. I'm making it so the user can personalize the content experience, rather than personalized for me. More like "Personalizable"

Janina: I haven't met you, but I love you. You have the gist, exactly. "Personalizable" is exactly what it is. This is huge, this is a curb cut - it's so very helpful.

<JennC> (Kerb cut for Kevin)

Janina: We know we have to go through CR twice - one with the issue of building this with HTML5, use the data dash prefix in your attributes. We've done that and followed the rules - so when we go to CR this is what we'll present. But then we'll have a different prefix. We just need to settle on the timeline.

Shawn: With my outreach hat on, I would like to have the new name before CR if at all possible. It minimizes much confusion later on. Chairs, do you want to ask EO to work on this, maybe survey to get EO members thinking of options, and discuss it next week?

Brent: Yes, we can start to think about options.

Kris Anne:I have a little bit of background about this and am excited as I'm in Assessment. Pronunciation of words does matter in an Assessment context, and this is amazing. And a week to allow the team to absorb that would be good.

Janina: I would be happy to share the demo video which has produced positive feedback. Mainstream audiences got it.

Brent: Next steps - the chairs will pull together some information and a survey to have the EO group take a look at it, either to brainstorm on their own, or make comments in a survey. Solutions can come up through this, this group is really good with that.

Janina:There are thoughts that the word "Semantics" needs to be in the name. It could be "content semantics module". We have made progress around the naming. I am happy to share the details for the invitation with meetings for the group.

Brent: Any other questions for Janina before we wrap up this topic. Ok, none. Thanks Janina.

Working together on EO resources

Brent: There is a link in the agenda to a comments section in our page on EOWG participation. We have a section on commenting.

<brent> Comments Section: https://www.w3.org/WAI/EO/wiki/EOWG_Participation_Info#Comments\

Brent:We have talked before, but we have noticed it helps editors for the group to be reminded from time to time - There are specific things you can do when commenting that will help the Editors immensely - the type of commenting, at the right time, and whether the commentator has been involved in previous conversations around certain topics. I want to call out a few things.

Brent: 1) To know what the stages are. The high-level reviews (Eagle), then the section reviews about a particular section (star fish and dragonfly reviews) and then the review that is very close, specific edits (monkey review). Then a polished review, which is where we don't want those comments to jump us back to lengthly comments. It's ok to bring things up, but hopefully this has been brought up previously, in prior discussions, rather just at that end point.

Brent:So EO will provide links to prior conversations and assistance to help you have context and comment at the right time. Also, to provide clear and actionable comments - what is your rationale for changing it, what you're after, why you disagree or don't like it - then the Editor can address it. They can reach out to say they've changed something based on your comments. And what is most helpful is when comments and suggestions are clearly stated.

Brent:One thing you should be doing is to provide the level of your comment - how serious you want your edit to be. If you want to point out something to the Editor that you feel is important or others would, you can put "Low". Or if it's more important, "medium" or significant, "high". ED-low, ED-medium. "This is low or medium to me, but I'll leave it up to you, the Editor, to decide."

Brent: When you mark something as High priority, this is telling the Editor that it is not up to them, to be decided by them - it might need to be put through a review again. Which is fine - this is something we want you to do, just clarify that it is a strong objection.

Brent: There is a template in the EO survey that reminds you of the levels, their definitions and how to use them. For example, you want to put the level, then the location in the text, and finally - what's really helpful - to put in the current wording, but then the suggested edit to the wording. This is extremely helpful for the editor, but also for others who are reading your comments. One thing I do, before I start opening GitHub issues is that I read the previously opened issues that people have left, so I can add my comment to other comments if it is relevant or related before starting something new.

Brent: It's important that participants register within the survey, even if you don't have time, or do not feel strongly about the topic. It's important for us all as EO group members to record our participation, even if it's to say "I abstain" for this survey. Editors, are do you want to add anything?

Sharron:A note that it's very helpful for the Editors, a real time saver, to add substantive comments to GitHub rather than the survey. We try to make allowances for those who are not comfortable in GitHub but it truly is the preferred way to submit comments and the editors can then use the Issues list as a kind of punch list.

<shawn9> [ at then end of this meeting , or others, we can show people how to put comments in GitHub ]

Kevin:For me, as an editor, GitHub helps me not to miss the issues and comments that are left. By the end of it, and there are no issues, I've done the job. GitHub makes it really easy to get to a point of consensus, but also open it up to others to comment.

<JennC> Brent: Also with GitHub, you can point directly to a comment or issue. Let the chairs know if you'd like to learn about how to access and add Issues to comments very easily.

Shadi: A big +1 to everything that's been said. As a previous Editor, it makes a big difference to the comfort level with understanding the comments. To add a time-related issue, the request for additional timing is very understandable, sometimes commentators need additional time, but one note to please use it wisely as it's difficult when significant comments come in late.

Shawn: When surveys are sent out, it helps when the Editors know ahead of time that someone will not be make it and are asking for an extension. It's best to say up front what you need.

<shadi> +1 to heads-up!

Daniel:For GitHub, we can put links to the new issues.

Brent: Good points. Any questions on this topic of survey and GitHub comments?

Sharron: The comments recently that have been really, really helpful. I've been grateful for the thought that is clearly behind the comments. It really has helped shaped the quality of these resources. I want this level of engagement and commenting to continue. Kudos and thank you.

<shawn9> +1 to EOWG participants providing even MORE thoughtful, helpful input and comments !

Kris Anne: This is very helpful. I will be more thoughtful about how much work is put into creating the content from the Editors. I know that learning how to use GitHub has helped me in the past.

How People with Disabilities Use the Web

Kevin:Thank you for the time spent in review and all the useful comments, Jayne, Mark and I will be working through comments in GitHub which are pretty straightforward. I will tag you in GitHub so you can see what we are doing.

Kevin: There are comments related to personas that are related to COGA work that are detailed and fairly extensive. Julie has taken on a task of a rewrite and adding the COGA expertise to this resource, very handy. We are also working on re-writing the "Alex" user story. We will clear out the smaller list, and then work on the larger ones. Please feel free to visit the Issues section on GitHub.

<kevin> https://github.com/w3c/wai-people-use-web/issues

Kris Anne: Wanted you to know Kevin that I have a meeting with a friend to provide information on the Deaf/blind user story persona.

Brent: Any further questions? Thank you Kevin and team.

Tutorials Update

Sharron: An updated version of the Tutorials is about to be published thanks to help from Steve, Shawn, and Eric Eggert, the original editor of the resource. Outdated content has been updated updated and corrected. The Tutorials have been brought into the redesigned web site layout and synced up with the design patterns. Brent is doing a QA review and once done will publish, hopefully next week. Eric assisted with the issues and Sharron will develop a maintenance plan.

Brent:Part of it is migrating the content to the WAI website. EO chairs will make you aware of the work so you can see it. Unless something major comes up, a review or survey is not likely needed. Any questions?

Sharron: Preview to the new content and layout is linked and we welcome your review. Thanks all.

Work for this week

Brent: Face-to-face meeting - consider filling in the survey to determine interest in getting together this year in person, either at TPAC or elsewhere. You can complete the survey but if your comfort level changes with travelling, you can go back and adjust your response.

<JennC> Brent: EO chairs will try to get a survey on the Personalization initiative.

Brent: I see no other topics or things to discuss. Does anyone have anything to share? If not, we'll talk to you next week. Thank you for a productive meeting

Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).