Meeting minutes
<julierawe3>: asked if the first pattern was clear for people. Once we get consensus from group it would move into github for public review.
No one needed more information or clarity.
Discuss key aspects of the 2nd V2 pattern: Clearly identify controls and their use
<julierawe3> https://
<Jan> As a point of clarification, the global-inclusion group came to the conclusion that "controls" is a technical term that is common in the field. They think that as long as it is defined, it's okay to use it.
<julierawe3>: In sharing the pattern Julie wwalked through its status, internal questions for COGA to consider, backrground resources and related patterns.
<julierawe3>: We'll be focusing on a few items in the What to Do section today. Asked the group what we think of having a call out box of 10 or so links in our document vs having a single link to have the reader visit a wiki to see the links?
Pros and cons of each was reviewed.
Rain: there might be a hybrid option. Include links to things we know won't change we include in the doc and the wiki link could take people to links to resources that emerge after we publish.
<Charli> Charli q+
Gareth: We could create a dropdown box of links to help reduce some of the cognitive load. Can use use text as links instead of seeing URLs?
Is it too much to provide a list of 10 links? If so, we can provide a dropdown for them.
Rain: Confirmed we do have the option to do this.
Charli: Do we have a mechanism for regular review and updating? If not, this will get out of date. In the absence of a robust mechanism we could start the link list with the phrase "some examples are.." and share the examples we feel will not change.
Rain: recommended not including links from Android, Apple and Miscrosoft since any of them could changed or outdated.
<Rain> +1
<julierawe3>: maybe include a 'be sure to check the latest from Android, Apple and Microsoft resrouces' to avoid the risk of referencing something that will change. It would be helpful to explain what we mean by 'platform specific'.
Jennie: since those links belong to W3C members can we link to a W3C asset that contains links or appropriate resources?
None of us on the call know if something like this exists. Julie takes it as an action item.
3rd item in “What to do”: Overlaps two WCAG 2.2 patterns about target size. What are we saying that is different from existing guidance? julierawe3]
julierawe3: Reviewed #2 (control boundaries) and showed that it was pretty straightforward.
Moved to #3 and asked if we should include it in our document since WCAG 2.2 covers much of this topic.
If we keep this topic in our guidance, what are we saying that is different than what is presented in 2.2?
julierawe3: Reviewed #2 (control boundaries) and showed that it was pretty straightforward.
julierawe3: Moved to #3 and asked if we should include it in our document since WCAG 2.2 covers much of this topic.
julierawe3: If we keep this topic in our guidance, what are we saying that is different than what is presented in 2.2?
Charli: This is another maintenance issue since we'll have duplicate info. Can we just point to 2.2 guidance? If we feel that it is too small, can we encourage them to update their guidance?
julierawe3: showed the WCAG compatibility section (already in doc). Given the frequency of change for WCAG, we don't need to worry too much about the maintenance issue.
<EA> +1 to Charli's comment
Charli: if our guidance is different we will leave people really wondering what to do with the conflict. We need to make sure if we feel the sizes need to be increased we should get the other team to increase theirs. We don't want people wondering how to deal with the differences.
julierawe3: We know that the reason 2.5.5 is AAA is that it is harder to acheive on smaller viewports (ex: phones).
Jennie: Knows that a lot of the conversations to arrive at 2.2 were people who have high need to access information in provate settings (where they may not have access to laptops / desktops). We need to amplify why this is important for our audiences and stakeholders. Asked for clarity on our purpose of text.
julierawe3: 2.2 will continue to exist. 3.0 will also have guidance on sizes which may be different than 2.2. How we keep these in sync is still an outstanding question.
Jennie: If we think about essential and emergency services, we need to look at our patterns to determine how important they will be on smaller devices. Control size is a very important pattern for these scenarios.
julierawe3: If we keep this (becuase is it so important for us) how do we refer to 2.2 in a more appropriate way?
Rain: Just finished a study on risks for challenges on specific sizes. Wonder if it's possible to hold on a section in our doc and come back to it when the study is actually published. The study was run on the smaller sizes proposed in WCAG. Might be avaible towards end of 2025.
julierawe3: That could be helpful and I'm open to considering this.
Jennie: asked Rain, how we could reference an upcoming study but still recommend that people follow WCAG until we know more.
5th item is about personalization: Should this item remain in this design objective or move to a separate objective about personalization? julierawe3]
Rain: agreed and stated it is better to err on that side until we have more information to change from the current guidelines.
<Jennie> * Clarifying: I am hoping we can recommend following the AAA requirement for target size for key information, until the further information becomes available.
julierawe3: #5 (ensure adaptive design can be personalized) we have two sections in our doc. How do we write these two sections? Write them fully in both places or have the sections reference each other?
<Charli> Agree with Rain
<Rain> +1 to lots of places :)
Exception: This pattern has an exception at the end, but should we keep it? If so, where should we put it?
Rain: Keeping them seperate - and focused on the sections purpose - and use a call out to send users to another section. This will help users see the distinction and more appropriately apply it to their tools. Mentioned someone using Wix who won't have access or ability to change something will feel like they are 'failing' if we don't show how
these are specific and can be used individually.
julierawe3: Introduced agenda item. 'Are we OK with a style being an exception?' Thinking of motion being an essential part of the activity. Is it OK have you control not look like controls? or be smaller than a recommendation?
EA: in the past we thought about banking quite a bit. There can be sites that require certain things to happen in order to provide extra security. It is something to do that is there for a purpose (maybe like a watermark) and might be distracting.
Charli: I think the idea of this exception related to security seems OK but we this shouldn't be used / applied to a game.
julierawe3: Interesting point about security. Should we add something here about that?
<Jennie> +1 to Rain - remembering conversations about school testing situtations too
Rain: essential here might be related to if the app is testing your ability to pick out color or imagery based on sizes. We'd need to make it clear how the exception applies.
julierawe3: encourages us all to add notes and comments to the guidelines to help us make things more clear.
<EA> I think there should always be an alternative when security is the reason for a style that is inaccessible