Meeting minutes
<alastairc> thanks DJ, I've added you to the list: https://
Announcements
Chuck: tomorrow I will host an onboarding class for AGWG. It is on this same link and same time. Duration is 1 hour.
<Azlan> Definitely interested in the recording
<alastairc> This puts the UK meetings an hour early for 3 weeks, probably for EU as well.
Chuck: This coming weekend there is a daylight savings time change.
<Zakim> kevin, you wanted to react to a previous speaker
kevin: if you are subscribed to your W3C calendar, the time should be automatically updated
kevin: anchored to EST
Chuck: Another announcement: CSUN is during the week when we're hosting AGWG on the 19th. We don't want to compete with CSUN. Chairs will be hosting a call at the normal AGWG session time. it will be a working meeting.
… those not attending will not be missing anything majoer
<Chuck> https://
Chuck: introducing accessibility supported and Alastair has a link and will chat about this
<jeanne> resent+
alastairc: concept from WCAG 2. There are some problems we need to solve for WCAG 3. There's an introduction. We go through the accessibility supported bit.
alastairc: Pulled out suggestions from previous work. How do we talk about it within the guidelines.
alastairc: Tried to capture remaining questions. Do we need same voicing of concept in WCAG 3. Pros and cons list the subgroup created.
… proposal for how to solve the problem for WCAG 3. Subgroup outlined options.
… if you get a chance, please look through the introduction and the materials a little bit. Think about what would solve this problem. Think about the international concept.
… think internationally. How do we deal with regions of the world where there may not be good assistive technology options/support/etc.
… proposals wanted on the above
Card sort results
alastairc: had a lot of outcomes and categorization
alastairc: 280 categories created. Two categorization approaches: 1) the interface (images, text, interactive component, layout, etc.), and 2) adaptive features (things you add to an interface)
… the latest exercise, 10 people completed each. A few completed both.
… It was a harsh test. There were no explanations for categories. Was a difficult task because the outcomes weren't very familiar to people yet. Difficult exercise without much context.
… Tool we used (Optimal Sort) produced minimal analysis
… highlights areas of strong agreement. Example, top ones had about 80% agreement, bottom end about 20-30% agreement.
GreggVan: These numbers are less an evaluation of the categories than the experiment itself. Without context it's unknown as to what is relevant to what.
GreggVan: Want to ensure we don't draw too much future decisions from this without the context of labels for the larger grouping.
alastairc: It is generally an indication of agreement level between understanding of principles
Detlev: The value of the results is that some of the categories is that some of the categories are harder to understand.
Detlev: it's good to know that some categories are harder to define and thus are an opportunity for refinement.
<mbgower> A great situation where "Discernible visual content" and "Undertandable visual layout" would really clarify
Detlev: in any case, the result will help us split the categories and refine their definition further
alastairc: average agreement favoured the interface approach. There are easier solutions to the interface approach
… I was favouring the interface approach as it seemed to have the fewest number of issues
… adaptive features category was quite a general category. My main problem is should we separate features. Do we have "provide support for search" go into forms and inputs? Some lingering questions.
alastairc: Lots of overlap with images, as they were put into media alternatives as opposed to images. Contrast was fairly straightforward. Headings were mixed.
… uncategorized outcomes were site-level, and placed into the "I don't know" category
dj: I think that this is a helpful exercise considering that we don't know what the categories or outcomes are entirely just yet. In sum, I value the exercise for its perceived benefits.
alastairc: combining some categories could be helpful
… putting "Adaptive features" into a concrete category
Rachael: are we going to back and consult the other sorts or are we doing the others after this one?
<Detlev> I would prefer slightly amor but narrower, better defined categories
alastairc: We will need to refine outcome names and titles. Once it's refined, where will it belong, perhaps a better category
alastairc: a "Policy" category may also be helpful for site-wide outcomes
… could do with a better name for the "Organisation across views" category
… useful to agree that this is a reasonable general approach. Will share link shortly.
alastairc: Continuing to refine outcome and category names.
<alastairc> https://
<mbgower> I think this is really valuable
Chuck: Maybe worthwhile to explicitly call out the reviewing of the categories as well so as to address concerns above.
WCAG 3 Requirement updates
<Detlev> AFK
alastairc: Review of the issues in the Requirements subgroup. Going through all issues raised for WCAG 3 requirements.
<Chuck> https://
alastairc: PR to add backwards compatibility section.
… WCAG 3 doesn't need to be backwards compatible with WCAG 2.
… After a first publication, the guidelines could be made backwards compatible
Chuck: did not get a lot of active participation in this particular review. Are we looking to give more time for this?
alastairc: At the end of this we'll be on the 5 day clock. if objecting, please post in github
GreggVan: If you ever add a provision, then the guidelines are not backwards compatible since you added provisions. If it's less strenuous, what passed before will continue to pass. If progressing, we will make it easier or make it harder.
GreggVan: Having a strict backwards compatibility is probably not good. It's confusing if you change the metrics on particular provisions.
alastairc: Not committing to the backwards compatibility but any change would be very cautious.
<Chuck> w3c/
<Chuck> w3c/
<Chuck> https://
<Chuck> Scope requirement updates from issues issue 729 and issue 224, resulting in PR 734.
alastairc: Not much discussion on this but if you have anything to add please post in response on Github.
<Chuck> Update the "Multiple ways to display" requirement from issue 726 with PR 733
<Chuck> w3c/
<Chuck> https://
<jaunita_george> +1 for having a conformance model
<jaunita_george> It's something we need to have in the US
Rachael: If anyone feels strongly that we shouldn't write a conformance model, the presence and agreement of this means that there will be a conformance model.
<Chuck> Will it be possible to tell whether a site fully or partially conforms? Response to issue 425
<Chuck> w3c/
alastairc: Jeanne drafted a response which acknowledges that this is an area of WCAG 3 that needs a lot investigation.
<Chuck> Will WCAG 3 provide guidelines for non-web technologies? Response to issue 611
<Chuck> w3c/
alastairc: [provides update on discussion occurring at the previous link]
GreggVan: Talking about guidance on non-web technology seems like we're sticking only within the web. Not sure that Rachael's response considers that web technologies are everywhere. Not sure if that's out of scope. Our charter indicates otherwise.
GreggVan: if we are going outside of web, then all fundamentals in WCAG 2 fall through. In WCAGICT, it's all the places we depend on a user agent. If no user agent, then all provisions need to be rethought.
kirkwood: I've had to deal with kiosks which are essentially using an operating system of a tablet that is using the browser engine to connect to the larger network of the business. That's a web technology. Does that fit into the scope or not?
alastairc: to Gregg and John, part of the intent of WCAG 3 is to decouple the assumption that there is a user agent. What does the user get and how does it work from the user's point of view. Underneath that we'll have a web layer that can start making assumptions about users.
alastairc: Moving to web technologies is that web interfaces are popping up everywhere. It seemed like a WCAG 3 compatible consideration.
<Zakim> GreggVan, you wanted to say That will make our job much harder but WCAG2ICT job MUCH easier.
alastairc: WCAG 2 requires a URL to some form of web content. WCAG 3 we're trying to decouple that
<alastairc> Yep.
GreggVan: If we do that, it will make some things a lot harder while some other things will be easier
Chuck: This doesn't alter our current scope for WCAG2ICT
<Chuck> POLL: Is Rachael's response satisfactory? +1 to support, -1 to object
<jeanne> +1
<alastairc> +1
<Chuck> +1
<bruce_bailey> +1
+1
<kirkwood> +1
<Azlan> +1
<wendyreid> +1
<maryjom> +1
<ShawnT> +1
<sarahhorton> +1
<giacomo-petri> +1
<Jennie_Delisi> +1
<laura> +1
<Detlev> not sure.. sorry
<dj> +1
<ljoakley> +1
+1
<scotto> +1
<Chuck> Do research across all the proposed guidelines. Response to issue 587
<Chuck> w3c/
<jaunita_george> +1
alastairc: [summarizes updates to discussion at above link]
GreggVan: I do worry that sometimes someone may say that some people will not have a problem without having seen it in the field. We should talk about research and cumulative knowledge of consumers. We should turn to consumers to determine needs and not just researchers.
<Zakim> mbgower, you wanted to say can you give an example of a user need that is not backed up by user research?
Chuck: got a sense about how it might be altered but not a direct suggestion
GreggVan: [makes suggestion]
<Chuck> ala
mbgower: Without research, how do we know what the outcome is without quantifiable identification of outcomes
alastairc: Some outcomes don't have much research, like landmarks and assistive technology use. We've given those a pass without needing research since there's so much user experience with such things
<mbgower> Re: screen readers: we've got data for that
<mbgower> The proposed wording sounds fine.
<alastairc> mbgower - it's hard to find research that isn't based on "this is what WCAG2 says..."
GreggVan: We know the need but no idea how to capture it. For some, sound causes seizures but it's hard to find solid research on this.
<mbgower> the Webaim surveys are an obvious piece of data for headings/landmarks.
<kirkwood> does this capture the concept of industry-accepted “best practices” ? or should we?
<Zakim> Chuck, you wanted to change scribes
<Chuck> POLL: Is Alastair's modified response satisfactory? +1 to support, -1 to object
<Chuck> +1
<alastairc> +1
alastairc I modified the comments with a minor update
<GreggVan> +1
<bruce_bailey> +1
<maryjom> +1
<Jennie_Delisi> +1
<dj> +1
<sarahhorton> +1
<mike_beganyi> +1
<giacomo-petri> +1
<laura> +1
<Detlev> +1
<Gez_Lemon> +1
Chuck that's all the WCAG 3 issues to review today
<ShawnT> +1
<kirkwood> +1
<Azlan> +1
<jeanne> +1
alastairc we're getting towards the end of the requirements updates. We have one more left. We'll need one more week to do that before we can get that to the main group
WCAG 2 items for review
<Chuck> https://
Chuck we're moving onto WCAG 2 issues now
mbgower we're in a midpoint in a two-week review cycle. Only 4 changes sent to review from the WG.
mbgower the first issue is trying to remove references to a version of WCAG 2.x. This is a normative change so need to bring this to the group.
… there's been a fairly thorough and careful review of this.
<bruce_bailey> https://
GreggVan some of these aren't normative, they're informative.
mbgower I'd love to get a citation on what's normative and what isn't
… we can take this offline
<alastairc> I think Gregg's correct https://
GreggVan I haven't seen an example be normative.
<kirkwood> Gregg is correct
mbgower PR 3680 relates to removing non-gendered language from documents.
<bruce_bailey> from link above: "...Introductory material, appendices, sections marked as "non-normative", diagrams, **examples,** and notes are informative (non-normative).
kevin on the normative / non-normative issue: there are 5 classes of changes. Depending on the type of change, that dictates the amount and location of the consensus.
… these changes will require re-publishing the documents.
<alastairc> I suggest we gather a few of these up and then republish later this year.
<bruce_bailey> thank you @kevin
<ShawnT> kevin is that documented any where?
<bruce_bailey> +1 to Shawn's question
mbgower the last PR is to update the xslt file to correct a typo in the display text of a mailto link
<kevin> Process: Classes of Changes
Chuck I think that's it for content.
Rachael: I want to point out that we're not getting many reviews on content on GitHub. We need at least 5 responses from people. If you have questions, need help with GitHub, etc., please get in touch.