Meeting minutes
<CarrieH> I guess I'm it?
<jtoles> Zakim Guide: https://
<CarrieH> I have auditory processing issues, so I can't scribe :\
<jtoles> move to Our subgroup definitions
<CarrieH> can someone share their screen or link to what we're working on?
Our subgroup definitions
jtoles all of our definitions have been added to all the other subgroup definitions. This was the focus of our AG call this week and should be the focus of our time between now and next week.
jkatherman was that the best use of our time yesterday? was that normal?
jtoles agree- that is not the best use of our time, seems like diving people the doc and then letting them make comments on it could be better.
jkatherman is that feedback we can share with the chairs?
LenB Julie is our favorite feedback channel for AG chairs since she's an AG editor and part of our group, but feel free to reach out to Alistait and Rachael if you'd like.
CarrieH recommended not working towards concensus decisions but think more of voting to help us move forward.
jtoles a major point of the discussion yesterday was we're going to be removing blocks of text and clear language as definitions.
<CarrieH> and perhaps during the call, give time for people to fill out surveys
<CarrieH> instead of having constant discussions or give opportunities to have a separate call to discuss thats specifically (that might not be feasible due to bandwidth)
<CarrieH> did we come to a decision to remove logogram?
jkatherman becuase context matters so much to the definitions it can make them very difficult to write. Concerned we stopped defining things because they became difficult.
jtoles we use definitions from CSS a lot because they are we-based terms.
<CarrieH> (non-developer here, but former User Assistance Developer/content author)
jkatherman we've been thinking in web-based terms and it is difficult to shift and define terms for non-web views and for non-developers.
<CarrieH> I agree with what jkatherman is saying that for content authors means different than from a developer
<CarrieH> also who's our audience? is our audience developers? or everyone?
jtoles agreed, maybe it's worth creating a glossary from other sources (like HTML spec, CSS spec, WAI glossary) - like a here are some terms we expect you to be familiar with.
<CarrieH> I'm autistic, and sometimes autistic people as we tend to be literal thinkers get hung up on how something is translated literally that some people take for granted. But not all autistic people or people with cognitive disabilities are literal in the same way, why that can be difficult..
jtoles our audience is supposed to be everyone.
<ashleyfirth> +1 to Carrie's point
<ashleyfirth> Also, are there any stats we're able to view? page views, search terms etc. to understanding who's currently consuming?
jkatherman +1 to carrie and we need to be open to other perspectives and ways of thinking. If we're going to be using terms we need to be very specific about them.
<CarrieH> I care more about being specific in how we're using them vs the word itself. Plus, some of this work is being done in silos...so each subgroup may have their own definitions/perspectives
jkatherman we may need more contextual definitions and not just terms that apply to the entire WCAG document. We might be boxing ourselves in if we have to think so that all terms can fit the entire document.
<CarrieH> Google doc tabs have a bit of a learning curve
<jtoles> zakim take up next item
jtoles pointed out that the document is grouped by subgroup definitions.
Other subgroup definitions
<CarrieH> If you go into the tabs view under "Draft Definitions" are subgroup tabs
jtoles does anyone have any concerns about the definitions from other groups?
<CarrieH> are we looking at other subgroup definitions in addition to our own?
jkatherman Hidde brought up the ideas around continuity with WCAG 2. How much of a concern should that be for us?
jtoles we should clarify anything needing it from WCAG 2. We don't 'have to' use the WCAG 2 definition.
jkatherman there was some pushback on a definition that didn't align with WCAG 2.
jtoles we should clarify anything we feel is not adequate.
Blocker survey
https://
jtoles some people have commented on our group's requirements.
… struggling how to tease out what we shouldl focus on.
jkatherman noting that some of these surey comments seem to support the idea that a definition we use applies only in this context (mentioned English-based). I'd like to float the idea that we create a model for contextual definitions.
… like when we have a requirement for text and wording so that it give us the flexibility to say 'in English, this is how it works.' This could help us solve some definition and requirements problems.
… interested in hearing how AG chairs think of this. Would like it be in a model so that we can apply all the right context for the guidance.
<CarrieH> some contexts might not be language specific, but rather region/country/cultural. For instance in the U.S. whether you're hard of hearing or deaf, generally identify as "Deaf" (capital "D") but in Germany which seems to be the only country this isn't true. Generally only someone that's completely deaf identifies as "deaf" (and that's not
<CarrieH> capitalized). So I think there are more nuances within context, so we would need to put guardrails around that too...
LenB I agree and think that language comes with more than just language rules, we have cultural elements that evolve a lot.
CarrieH agree on the cultural elements and shared a few points from the deaf and hard of hearing community.
… agree that we can have contextual but we'd need some real guardrails around this.
jkatherman yeah, we really need a model to provide the flexibility and the guardrails to keep us all aligned.
CarrieH our risk is that we only consult with internationalization group since we don't have the representation on our team.
<CarrieH> Internationalization team may only think of it in terms of language but may or may not think about cultural nuances (or they might, I don't know people in that group)
jtoles the way we have it laid out in the tables assumes that all of these languages will have the same characteristics and issues.
<CarrieH> I will need to drop off, as I have another call I need to prep for...
GitHub issues
jkatherman we have different requirements for different languages and we should also think of different cultural norms and other characteristics
jtoles we need to approach github as our way of collecting our ideas and tasks.
jkatherman a suggestion: we could make some assignments in our meetings so that we can get action on these.
jtoles would working asycnh work better or make the assignment in our calls?
LenB I think we should prioritize them somehow and then assign to appropriate people.
jtoles I can review what's in github now and come back with priorities
LenB should we add all of our work in Github
jtoles that may be case by case, some are worth adding to github others might be way too much
jkatherman it does feel like things we'd want to share with other people / groups it might make sense to add them to github.