Meeting minutes
Introductions
Rachael: Introductions — anyone is new or in a new role?
announcements
Rachael: Next week is the first week of the month and we start half an hour early for an introduction for onboarding; feel free to join 10:30 EST to ask any questions
<kirkwood> link to the charter?
kevin: Our charter was due to run out on Thursday; the charter is what we run under and we are limited in what we can do if we don't have a charter. I asked for an extension because we have last minute comments to address, hopefully we have a PR that addresses that as soon as possible. Hope by end of the week. Then will be submitting for AC review.
kevin: We've made changes to the PR, not the charter, there are disposition of comments that I will need to submit with the charter and then will be open for AC to review to determine whether or not it is acceptable.
<kevin> Charter strategy issue
bbailey: Are we permitted to continue as usual, unless we hear differently?
<kevin> New charter
<AWK> Will the WG be able to review/approve the charter with the updated changes?
kevin: We've got an extension until end of August but I'm not intending on taking us that long because we have to ensure we have time for the AC review and that needs 28 days — 4 months? If not, we'll need to go back to the internal team
kevin: In reply to AWK, the answer is no — all we're doing is continuing talking about the charter than necessarily addressing issues and work. We'll accept feedback, AC review takes it to another review cycle where the EC can comment on the charter and feedback on that.
wrap up scoping conversation https://docs.google.com/presentation/d/1BkgIVS8ODwokDPXJd91ChHfN7-WuaZdGcvK3Ru-hc_Y/edit?slide=id.g3e060b64ff9_0_10#slide=id.g3e060b64ff9_0_10
Rachael: First topic is to review the scoping conversations; same slide deck last week.
Rachael: We'll be on slide 10 titled "April 28th" and it is no longer a draft because we are in the meeting
Rachael: (shows her screen of the presentation)
Rachael: Last week we did an exercise to narrow down for WCAG 3.0, what do we mean with WCAG 3 as a whole? There is consensus from the survey that when we say digital content in WCAG 3, it's almost certainly web content but there was a high consensus around non-HTML documents and around desktop and mobile native applications
Rachael: We had general support of people voting for ICT with video capabilities, wearable applications, some form of extended reality, and some overlap between that and web content. Less support for closed system software like kiosks, TV-top box applications.
Rachael: The proposal is coming to the group to start from our conversation today on the scope.
Rachael: We would commit to writing provisions and informative documentation for WCAG 3.0 for web content, software, and documents — where the consensus was. And when writing those provisions, we will consider the following platforms so we won't write the informative content for them, but we'll think about them. Try to make the provisions applicable as much as possible for ICT with video capabilities, wearable apps, extended reality, etc.
Rachael: If a provision applies for web content but can apply to ICT with video capabilities and wearable applications, we will write it with those in mind but not going to write one that are specific to the ICT/wearable apps.
We could have a potentially core re quirement that was something like captions remain in the view — say it's possibility as an examplar, saying captions are presented within the view along with the content
In 3.0 we would write informative content around that so techniques and test procedures for web content for software and documents, but in 3.1 we might want to write the informative content for immersive content, and in that case we might have techniques around 360-degree digital environments that fall under this core requirement
Rachael: ^
Rachael: (reading slide 15 on WCAG 3 - Revisions basd on last discussion)
Rachael: (goes back to slide 12) Open for comments, questions, thoughts
GreggVan: On your captions remain in view — should probably think about captions can remain in view because you're taking away the freedom of someone who wants to have them on the side not in front of their face
Slideset: https://
GreggVan: Left out telcomm and a number of other areas — my concern is 1. you can't draw lines when trying to draw them when we talked about mobile, there are no clear lines for some things like in EN 301 549, you'll find that there is no such thing as closed products, only closed functionality.
GreggVan: It will be open to some, closed to others, etc. and trying to get out of hardware, you'll run into problems because you don't have things that are fully or completely open, most mobile products like iPhones are partially closed but they're not open to any other AT — is that open or closed?
GreggVan: You need to expand this group to a whole bunch of other additional expertise that it doesn't have
<Zakim> Jennie_Delisi, you wanted to discuss backend comment, slide 13 and 15
Jennie_Delisi: I like the way this is laid out, helped me think through some way that you share the information. Re: slides 13 and 15, does this mean that if it uses a web interface and someone has it as an essential job duty to ensure that the application works for other users, e.g. admin of an application if there are interfaces specific to that backend admin role, will those not have to comply?
Jennie_Delisi: With the way it's written right now, if I had an essential job duty to administer that backend I want to make sure it's covered for places that says to conform to 3.0
<Zakim> Charles, you wanted to clarify ‘consider’ and ‘think about’
Rachael: What we're trying to say here is backend processes without user interfaces — if you have suggestions for better wording on that, we welcome that
Charles: It's still murky on what is mean by what we will consider — my general understanding is the provision level is technology agnostic anyway — should it be agnostic but being agnostic could in the future cover these other technology-specific methods
<Zakim> alastairc, you wanted to comment on drawing lines. Whilst trying to keep it applicable across digital interfaces, we have areas we focus on, areas we do informative content for, and things we say to people that it applies to.
<Jon_Avila> Maybe for the operating system piece - we clarify that we are talking about aspects beyond what is covered by the standards - not that the WCAG 3 standards couldn't be applied to operating systems.
alastairc: On that specific bit, we're trying to make the provisions agnostic so in that case the writing bit wouldn't expand into that area to find requirements unique to it but we want to check we aren't making them incompatible with those technologies
Charles: What you're saying is what we will not create is a provision that would only apply to these specific tech?
alastairc: Yes
Rachael: Added that clarification in the slides
<Zakim> kevin, you wanted to ask about web tools that provide functionality that is outside of our focus, for example, in-browser video conferencing, WebXR
kevin: Just to break off that last comment, I'm interested in web tools that provide functionality that we're classifying as outside our scope
kevin: e.g. in-browser video conferencing or webXR — so depending on how you want to define web technologies, they would need provisions that would cover them according to the agree scope but they would fall within because we're not necessarily talking about how to do something that falls outside of our scope, so it's a bit unclear for both of those
<Zakim> AWK, you wanted to share concerns about the ability of the WG to address desktop software to the level of comprehensiveness we can for the web. Is this reflected in the charter?
Rachael: Something for everyone to think about: 2 questions: is this one kind of approach of allowing writing for this scope but focusing on this particular set that later on for future versions allows us to extend beyond that; and second question is what fits in these different boxes if we want to move forward with that
<Charles> +1 to the idea of extensible scope
AWK: Yes, we need to be able to draw these lines but similar to Gregg's question/concern about whether the WG can deliver guidelines and standards related to desktop software, maybe even true for native mobile apps, but right now I don't think we're equipped to provide/deliver standards for desktop software in the way we are for the web
AWK: Related to who's here. I don't see this in the charter draft where desktop software is covered and I think before the WG can create standards that apple to desktop software, I would expect to see that in the charter
GreggVan: Drawing lines, we can say we're only doing web but all of a sudden you end up with VR, we're going into hardware which we don't cover — you'll keep running into these kinds of things as soon as you walk out of web
<stevef> WCAG 2x includes PDF - not a web technology
GreggVan: The term backend came out of a policy not a technology, had to do with the buttons that would have to be within the reach of somebody in a wheelchair, it's not a type of technology. Backend technology, in EN 301 549, if it has a user interface you need to do this.
<AWK> stevef it is if delivered in the browser
Rachael: Is that the solution to say that we shouldn't w rite things for things without user interfaces?
<alastairc> stevef - Gregg would say PDF is web when delivered by URL
GreggVan: No but you'll notice we didn't put that in all of the provisions, so if there's software without a user interface, there are some rules that have to apply to them
<AWK> alastairc Gregg is right in that case. That is the basis for there being PDF techniques for WCAG 2.x
GreggVan: You can run native mobile on desktop so I'm not sure what native mobile means
<Charles> GreggVan is an API then a backend process?
<stevef> Most software is delivered via the web (links)
GreggVan: It has more to do with screen size, being open or closed, etc.
<bbailey9> Just FYI, since I took a look, link to results of scope survey from last week mentioned on slide 8: https://
GreggVan: iPad are as big as laptops; just saying we're having trouble when we start wandering outside of web in terms of figuring out where to draw lines
Rachael: We did change the wording to just "software" and meant both desktop and native mobile
Rachael: It was on the previous survey
<Zakim> joryc, you wanted to say can we lean on "ICT"
<stevef> we should remove PDF unless its rendered in a web technology
joryc: I want to put in a vote for not even discussing specific devices or platforms. I think that's doomed. For the next 3 years there will be so much new stuff, new interfaces, can't we just lean on the subset of ICT that is digital? ICT is just computing + network and that's what we're worried about — is there something we want to cover that would be covered by that as a concept?
Rachael: What wording would you put in for us?
joryc: I'd just say digital ICT or something to that effect
Rachael: What do you see that including?
joryc: Getting away from trying to include/exclude particular content — anything that is a form of computing that conveys information is digital ICT, if it uses networking, and I think that's what we're talking about and some things we might want to exclude from that — everything we're listing right now would fall under that except for kiosks maybe
<alastairc> AWK - but PDFs can be delivered outside URLs/browsers as well. It's not a great dividing line, although I'm sure useful at the time.
joryc: The web, CLIs, digital interfaces on the screen, anything digital ICT — ICT-specifically defined through categories (hardware, we don't have to touch; software we want to touch; networking we don't want to get involved in), the software/applications that make up ICT or digital ICT is considered inclusive of just about everything we talked about — web, mobile, PDFs
Rachael: I think when you say digital ICT instead of digital content, that is the large potential set that we want to narrow down and focus on
<Charles> opinion: the ambiguous superset path will always be a challenge for policy and legal adoption that relies on specificity.
joryc: Otherwise people are trying to judge if we have a list of things that are supported, is it likely for this to be covered in WCAG 3.0 or not? Is this a "like" thing in these other categories you named, like a wearable or XR?
joryc: I'd move towards a more umbrella category recognising what has been called out around expertise that is out there and those sectors are looking for guidance and trying to apply WCAG to it, maybe bringing that WCAG to ICT approach would be something to consider
<shadi> +1 to Jon_Avila
Jon_Avila: The challenge is that the provisions can be applied to these areas but we're not saying we're covering all aspects of those areas, e.g. OSes, the provisions would apply to an OS but they should be used for the UI, we're not addressing the platform requirements, not saying this is the list of all things to be done to make an OS accessible
Jon_Avila: because they would be other accessibility features that need to be available that we can't cover initially and the same thing would go for software or other types of things — we can create standards but we can't say we cover everything
Jon_Avila: I agree with Gregg on the backend; it's problematic potentially because it was meant as an exception
Jon_Avila: The European standard and CVA and other standards have requirements for preservation of accessibility information being transmitted across the network
<Zakim> alastairc, you wanted to comment on drawing lines. Whilst trying to keep it applicable across digital interfaces, we have areas we focus on, areas we do informative content for, and things we say to people that it applies to.
Jon_Avila: There's also platform software, we we don't want requirements to apply to a platform but there are additional requirements we haven't identified that would also be necessary
alastairc: In my mind we've got concentric circles of things; platforms that we are focusing on and writing informative content for; things that we want to check, things that we're not making things incompatible for
alastairc: When we get to 3.1 we don't want to have kind of drawn ourselves into a dead end; just checking that the provision doesn't cause us issues in the future
alastairc: WCAG 2 is already being applied to web and software and we want the provisions to be tech-agnostic as possible. I agree with AWK we should be careful talking about desktop, software; just difficult to differentiate in mobile and the mobile task force can be writing or checking things on what is native but not on desktop — can anyone think of differentiating those?
alastairc: I don't agree with GreggVan on always having to get into hardware as soon as you get off web, there's an accessibility-supported route where we take into consideration the capabilities of the platform
<Zakim> Rachael, you wanted to say we are already into the lines problem
alastairc: We can treat it as an accessibility-supported issue without getting into the hardware
Rachael: We have to figure out where to draw these lines and we can't just say web content — going back to the start of the conversation that web content is in different pieces, some in software, mobile, documents, etc. so this may be the wrong approach but we still need to figure out what the boundaries are, not simply say web content
Rachael: We need to scope, talk about the scope of what we will be writing
<Zakim> hdv, you wanted to mention policy needs and pragmatism around scope
<stevef> +1 to Rachael
<CClaire> How about hardware + software integration devices? i.e. smart whiteboard?
<alastairc> bbailey9 - I'd also note that some provisions may require things that are not available in the platform - and that's ok if it means it identifies accessibility gaps in the platform. (And it means authors have more responsibility on the less accessible platform.)
<kirkwood> +1 to Hidde
hdv: I like a lot of the approaches to answer that questions, from a government perspective we want to regulate such that people with disabilities can use things and we need requirements to assess that against — mobile and native is hard to define but worthwhile to do it
<stevef> +1 @Hidde
hdv: What we've got here: digital software, digital products, digital ICT, we need to use general words like that, as long as they help us use the same requirements, let's just stay agnostic
hdv: WCAG 2 did quite well altho it has web content literally in there, it helped us do thing somewhat agnostically and be able to apply things broadly
hdv: We do need to conquer how to make that work with the membership also because not all members are in favour of doing this, but some are and it would be worthwhile to continue exploring
<AWK> Rachael what is "they" in your response?
GreggVan: In EN 301 549 we talk about OS, three functionalities, there's code that doesn't affect the user interface and we stay out of that because we don't want to tell companies how to architect things — stick with the outcome, not the processes inside
GreggVan: The OS have user interfaces, the browsers were part of the OS until legislation stopped them — there's lots of other parts, but if you really want to, talking about digital ICT, that's what EN 301 549 is and if you want to go beyond web, just use EN 301 as our basis instead of WCAG 2 because EN 301 contains WCAG 2 in its entirety, plus it has all other parts that you keep wanting to add in and it's restricted to digital ICT
<Jon_Avila> ChromeOS seems to be a web-based operating system
GreggVan: It would be a better place to start since it has all WCAG, WCAG2ICT, etc. other aspects we think want to get into but not sure what they include
<alastairc> Jon_Avila - plus it can run Android apps...
<AWK> Rachael "there is no try" Needs to happen.
GreggVan: The hardware issue that alastairc brought up, as soon as you go non-web, you will encounter closed-functionality, and you'll need to talk about alternate approaches — can't do that without hardware requirements. It's not that you want to get into hardware, you need hardware but can't talk about alternate, but you have to talk about alternate if you talk about closed functionality
<stevef> what is closed functionality in terms of iOS/Android?
<alastairc> stevef - have a look at slide 16
<stevef> Hard No to limiting WCAG 3 to web only
GreggVan: I think we should walk before we run; say we stick with web but write it so that it facilitates generalisation to other technologies, once we figure out how to do that for WCAG 3, we can say in WCAG 4 we can generalise it that will keep us from having WCAG 3 stretch out
<Zakim> bbailey, you wanted to give +1 for WCAG3 to be written so as to be compatible with non-web ICT but suggest we make peace with the that fact that accessible gaps will still exist
bbaile: The exercise on the requirement to not convey information only with sound that works perfectly well as a requirement in WCAG 2 and had all these implications once I started thinking about non-web ICT — from this discussion I am thinking about what the other things are that we don't address, but we need peace with the fact that there's a lot that WCAG 3 can't address
<Zakim> Rachael, you wanted to strawpoll
Rachael: Want to strawpoll this approach to see if the approach is right to start narrowing how we draw lines
GreggVan: When you say extensible approach, but everyone talked about things that have to be changed or tweaked — don't know what it means
Rachael: We'll write provisions and informative docs for something and also consider things when writing so we don't write the things we write without considering other technologies and we won't create provisions for some larger subset, focus on the smaller subset
<Jennie_Delisi> 0
<Glenda> +1
<julierawe> +1
<Heather> +1
<ShawnT> +1
Rachael: Is the concept of bounding it into 3 categories works
<GreggVan> +1
<erinevans> +1
<bbailey9> -1
<LoriO> +1
<alastairc> It could be us writing things, or we could leave that to others.
<AWK> +1
<Azlan> +1
<eloisa> +1
<alastairc> +1
<janina> +1
<Charles> +1 to extensible scope, but we shouldn’t define the future version the extension would occur in.
<GN015> did not understand the poll
<Charu> +1
<Monica> +1
<Makoto_U> +1
<Jon_Avila> +1
<Jennie_Delisi> (my zero is also in reference to why I got on queue)
bbailey: (said -1) I would rather phrase "we will write for web content and will make sure we don't introduce incompatibilities with software and documents"
<CClaire> +1
<shadi> agree with bbailey9
Rachael: I think it's the same concept here but you would prefer that wording
<Detlev> +1 I don't know - I'm caught in a groundhog day feeling
<GreggVan> +1 I you mean the method could include "write for web, think beyond, don't go beyond til after we get done with web and get it out"
<AWK> Suggest "make an effort to avoid introducing"
<kirkwood> +1
<laura> +1
<bbailey9> +1
Rachael: bbailey if we explore that wording as a way of explaining this, I personally don't see them as incompatible
<LenB> +1
<SydneyColeman> +1 with the clarifications discussed (gregg's in particular)
<jkatherman> +1
Jennie_Delisi: One of the things the discussion is helping me remember is a part of my daily work is my overlap on things on the counted list — somebody might define as hardware has web elements that must be used for that to function — I don't know if that means we need to specifically we're talking about it but we need to address the overlap
<SydneyColeman> +1 with web as p0 and others as 'nice to have'
Rachael: Ties in with what kevin said earlier to reinforce it
Rachael: (editing Proposed wording slide)
<Glenda> See AWK’s comment Suggest "make an effort to avoid introducing"
Rachael: (^ slide 14)
Rachael: Will capture things as we keep having this conversation
<Zakim> Jennie_Delisi, you wanted to discuss link between hardware and web in many cases
<stevef> +1 to scott
scott: I'm worried that writing specifically for web content will introduce barriers to allow guidelines to go beyond web content — I was thinking of what others said about being agnostic and writing WCAG 3 guidelines that don't expect a particular technology, the current scope is for web content
scott: because they would be other accessibility features that need to be available that we can't cover initially and the same thing would go for software or other types of things — we can create standards but we can't say we cover everything
scott: If we write rules that focus on what the user need is and then different technologies can address that need is based on what's available, I could see that being more successful for when we go beyond
<Charles> note: html includes code that does not affect a user interface but may affect assistive technology like the language of the page. so we need to refine ‘a user interface’.
Rachael: Thanks for regrounding us on that, we didn't want to move away from outcome-centered technology agnostic guidelines
<Zakim> Rachael, you wanted to react to Jennie_Delisi to scribe change
Rachael: Scribe change?
<GN015> +1 to Gregg
<alastairc> Ben_Tillyer, so a "super app" is something that is essentially a do-everything app?
Ben_Tillyer: At the Advisory committee meeting last week, a topic that came up was about super and mini apps which are common across Southeast Asia; they have a closed ecosystem. There is a gray area for determining an operating system, and isn't sure where these apps sit from a definition standpoint. Point two, to Greg's coda that doesn't affect a
user interface, it's indirectly all code; it affects user interfaces ins one ways whether that's how much time it takes for the page to load. Third, for the overarching conversation of web versus non-web, my guts says that the guidelines must be web-content focused, but we have to acknowledge that the users may not know when they've passes from web
to non-web. I think we should embrace that and call it out, but not focus on writing guidance.
stevekerr: In regards to something that Greg was mentioning earlier about EN incorporating all of WCAG 2, EN fort of implements WCAG 2 for non-web. their clauses sometimes omits some of the requirements of WCAG 2 for non-web documents and software. Wanted to ask if we will run into situations where we do have requirements that are just explicitly
not applicable on some of the non-web platforms?
Rachael We do have a 'where applicable section' in all of our provisions, so I think we would scope them; Alastair says he'll speak to that in a moment.
<scott> FWIW, i would really like it if guidelines are written specifically for the web, that it's overtly stated as such
joryc: Put himself on queue a while ago when Greg was talking bout the inevitable slide to hardware. Thinks he can easily stay out of talking about actual hardware if we think about outcomes. Thinks we have plenty of conformance of WCAG to other technologies when it's not applying to the platform. As for the length of time this is taking, what if
we just combined WCAG2ICT and WCAG as a whole?
<stevef> cognitive dissonance: I spend a large part of my professional time QAing issues for assessments conducted on iOS/Android apps against WCAG2x
<Zakim> alastairc, you wanted to comment on how to keep things widely applicable
GN015: WCAG means "Web content," thinks it could be "W3C Content Accessibility Guidelines" instead. People usually think web pages. Users sometimes don't know whether they are in a web application or a native application specifically on mobile. We can go for naming this generally if possible.
<Zakim> GreggVan, you wanted to say better to say "exclude software functions that do not affect user interface or availability of alternate forms of information" than "exclude code that (anything)" because that implies we are including other code. We should not be saying anything about the underlying code for anything even user interface. just the behavior of the user interface etc.
alastairc: How to make things apply widely - essentially reviewing from the point of view of different platforms; it shouldn't be a massive task, thinks its a task for us to go through and essentially see what maps with EN 301 549; where we look through and not copy it, but integrate it so the applicability works, which would speed us up on the goal.
<bbailey9> +1 for using making use of ETSI work and how they adopted WCAG2 provisions for non-web ICT.
<alastairc> agree, there might be cases where we set applicability to web-content only, and have a separate provision for other platforms.
<Ben_Tillyer> Surely we require the web app that is being measured should be able to output sound via hardware - hardware isn't our jurisdiction
<Jennie_Delisi> Example to support Gregg's point and my previous one: lab equipment. Functions on the hardware might be controlled via web interface.
<alastairc> GreggVan - you've been hearing that for several years now.
<Charles> +1 to GreggVan about hardware IF we say that web methods do not prevent hardware methods. example: hardware volume buttons that adjust a range input.
GreggVan: Don't use the word 'code' use the word 'functionality' because it implies that we are going to have rules about the code for things that affect the user interface, and we don't. We want to have requirements around the behavior of the software. Also, for everyone to understand, every provision in WCAG, including AAA, in EN, there is
nothing to do with web that isn't identical. We found after a lot of research we found two examples, both of which are now off the market. One that just doesn't apply that way, but the other ones, there's a bunch of element that have a whole bunch that apply differently, and you can't just substitute. For WCAG2ICT, you can't just apply things. If
we're going to go outside EN 301 549, I would read it first. Everyone keeps saying that we don't have to inevitably slide into hardware. For example, hardware needs to have a sound output, but privacy applies, so you need a headphone jack. There needs to be a standard way to use one hardware with another. Additionally, it needs to be tactically
discernible. VoiceOver on iPhone is tactically discernible because of the all the gestures that are made available on the surface of the screen. There are alternate ways you can do things with sound, but you can't rely on sound. WCAG 2 used your extensible model and it rolled for the web. It tried to keep in mind everything else. It was agnostic as
possible. As we go into WCAG 3, it sounds like there are two missions: Take WCAG 2 to go beyond the coverage of people with disabilities and the second, which is to go beyond the web. Both wonderful goals, but it may take years to do. I think in WCAG 3, we try to figure out how to expand it to cover more disabilities, and table adding additional
technologies for another time.
<Zakim> AWK, you wanted to say we need more than technology-agnostic provisions to meet the web. Perhaps "technology-agnostic guidelines, and provisions applicable to web-based content" and then the extensibility is developing provisions for domains beyond the web.
Rachael: Recognizes the support from Charles in his comment above.
<kevin> WebXR applies to the web surely?
AWK: Point out the wording that's now in the top of this, where it says, I agree, we should identify technology-agnostic guidelines, but I think that we're trying to create a very specific provisions that apply to the web, and maybe something else beyond the web, but it's basically that we are covering the web, and we think that it'll work for
other domains. There's a layered piece here, it's not just technology agnostic guidelines and provisions and web-specific informative guidance. We need web-specific provisions as well.
Rachael: Makes sense to me, but I don't agree.
AWK: Just thinking if we had WCAG 2.X, had technology-agnostic guidelines and all the success criteria were technology agnostic. Techniques and understanding that was specific to the web.
<alastairc> We can take in the learnings from WCAG2ICT and WCAG2Mobile, and make sure the definitions and provisions allow for wider usage.
<kirkwood> content rendered in a browser
<GreggVan> nd diabilty coverage and expand technology coverage.. But we also agreed to get this done in less than 6-8 years. We also agreed to a lot of things we would like. We now have to figure out what we CAN do in the time we feel is acceptable. We CAN do BOTH but not in that timeline.
Rachael: Wants to pivot because we have a core disagreement, and it's something that has been decided previously several times. There was general agreement in the group to move away from just web content, that's why we renamed it, and why a lot of things said digital content for years. So that concept of broader is kind of a foundational decision
in WCAG 3. If this is not a good way to describe it, web content software documents, those are not the right categorizations for us to move forward. Let's pause and stop about this. How do we draw the lines for ourselves to best write what we are working on? How do we articulate this to ourselves, and ideally in the charter and for the work
documents, we know what we're writing to. Want people to pause and make suggestions. Please keep statements as actionable as possible.
<kirkwood> content rendered natively in a browser
<Jennie_Delisi> Suggestion: applies to HTML and (if applicable) to tools created by the owner (?) of that HTML that impact those other tools' functionality. Example: lab equipment which relies on HTML for adjustments to functionality, updates for the hardware, possibly functionality like use of AI which "talks" between the hardware and HTML which has settings
<Jennie_Delisi> controlled in the HTML.
GreggVan: On your pivot, we did agree that we would expand disability coverage and technology coverage, and agreed that we would get it done in less than 6-8 more years from today. We have to figure out what we can do in the time we feel is acceptable in the timeline. Second, the beauty of the extensible approach is that we will write it for the
web, and we're not going to not include something because it would be web, and it won't work someplace else. If we do that, and the write it as broadly as possible, and that most of them can be applied more broadly for WCAG2ICT, just by swapping words. Why should we make that note in the ICT so that it's there for us when we do the next stage,
which is to expand the technology. I think if we focus on expanding the disability, and we can try to make everything as technology generalizable as possible, we could leave notes behind for the stuff we haven't figured out yet.
<stevef> -1 to not covering mobile apps
<Charles> thought: provisions are still functional needs based and outcomes measured. the human is centered, not the technology. identifying the tech only applies to methods and test procedures and exceptions. BUT naming the scope is most critical to those who adopt guidance into policy and law.
<Jennie_Delisi> Agree with stevef
alastairc: To expand on a previous bit, the kind of things that WCAG2ICT brings up, such as definition of page, etc., there's a few definitions that drove into a bit of a 'web corner,' and there are things that are actually very applicable. I do think we can build it into our provision review process. We need to make sure we don't break
compatibility with those platforms. We should understand and accept that certain provisions may not be doable on certain platforms and that's ok if it's highlighting an inaccessibility of that platform. We don't write extra content ro it, we don't expand into those areas, we minimize incompatibilities.
<AWK> FWIW I agree with stevef also re mobile apps, but we need to ensure that the W3C supports the publication of such a recommendation outside of the web.
<Zakim> Rachael, you wanted to strawpoll
Ben_Tillyer: In reply to Gregg's comment, web content means http, https, that's only a subset and it's an ever-growing area, and how web view components are delivered. These may not delivered through https or https.
<Zakim> GreggVan, you wanted to say agree with alastair as long as we don't imply that we COVER those other areas. Just that SOME of what we are writing - covers some
<stevef> people already think they are done with accessibility doing the WCAG
<kevin> It is not clear that that is the definition of 'web'
GreggVan: For the last two comments. As long as we are clear we are not writing for the other areas; if we saying we are writing for web (and that some may apply to these other areas because they are incomplete), because they would be misleading. As soon as we propose that we are covered more than just web, people may not do anything more. Secondly
about http, all of what we just said; as soon as you use the technology to wrap it, to make a native app, it is no longer a web app, it is no longer through http; you no longer can get it through any browser and all the browser assumptions. It's the https and all the things that get pulled into it. The definition of a web page is that the interface
is served to you through http.
Rachael: There is disagreement on the definition of web page. Moving forward with this to the straw poll.
Rachael: Wants people to write in each of what they support. Web, Software, Documents.
<kirkwood> Web, Documents
GreggVan: Is this for 'comprehensive' for web, document and sofware?
<Rachael> Straw poll: Which do you want to write comprehensive guidance for (note all that apply) in 3.0: Web, Software, Documents
<shadi> +1 to alastairc
<stevef> web/software/documents
<Ben_Tillyer> web/software/documents
<Zakim> alastairc, you wanted to provide a suggestion "WCAG 3.0 focuses on provisions for web content. The provisions can also be applied to software and documents but are not considered complete for those platforms in 3.0. Future versions may provide additional guidance specific to other types of digital content."
<janina> web -- nervous about documents. A musical score (Beethoven symphony) is a document
alastairc: Reference wording on slide 18 of the deck.
<LoriO> web/software/documents
<janina> software should be a revival/next steps of UAAG 2
web/software/documents
<Rachael> link: https://
<GreggVan> web -- in way that is generalizable to the others as much a possible but don't promise comprehensive for the others. MAYBE docs but not software or anythign non-web that has active elements
Rachael: Proposes modifying the straw poll to adopt wording on slide 18.
<alastairc> Ben_Tillyer - I think Gregg's comment was that you can't use your own browser.
<AWK> That is "web technology", agree
<stevef> mobile apps (non web) makes use of http protocol
Ben_Tillyer: Greg, there might just be a misunderstanding on these technologies. With Electron and Tauri, the bundle the HTML serve the code somewhere and then use a browser. Software may serve content to assistive technologies differently, but the content may still be accessed.
GreggVan: What you just said may not solve the problem.
<Azlan> +1 to shadi
shadi: Wanted to come back to the straw poll; feels that it is a bit suggestive. Wants a lot of things, but what is realistically manageable within this working group. I think the way Alistair Is phrasing it is implicit. I'm mulling over the want.
Rachael: Original straw poll is out. Updated to wording proposal on Slide 18 [read slide].
<AWK> WCAG 3.0 targets a comprehensive set of provisions for web technologies.
GreggVan: Thinks this is really good; paragraph 2 "as applicable as possible." Then WCAG 3 on the next one focuses on a comprehensive set of provisions for web content. Nothing will ever be comprehensive. Next, many of the provisions can also be applied but are not considered complete for those platforms. Putting that many of the provisions can
also be applied, and I think this really talks about the focus on the one. Write them as broadly as we can't but don't promise to cover all those other ones.
<stevef> how do we know what can be applied until we have written them?
<bbailey9> Gregg edits are addressing what I heard @shadi express concern for
<alastairc> acl alastairc
alastairc: Thinks about how our review process should work; was trying to get at we should be using WCAG2ICT and reviewing the provisions from the point of view of software and documents, so that we aren't creating imcompatibilities.
<Charles> thought: the provisions intend not to conflict with or prevent software and document methods.
shadi: Wondering if there's more we can say than these guidelines would inform related web tools, such as user agents. If we want to comprehensively address content, we need to do more than just considering particular user agents, authoring tools, and AI agents, but really be used on them in a way or have something stronger there. Reacting, but
don't know the exact phrase or words.
<Zakim> GreggVan, you wanted to say "The provisions will be written to be applicable to as wide a range of technologies (e.g. cocuments and software) as possible....
Rachael: Made note of Shadi's. There weree some questions about the concept of functionality that does not affect user interfaces. We want to sue that instead of ICT without a user interface.
GreggVan: I think it's a good point; we will actively write them to be applicable to as wide a range as possible.
<Ben_Tillyer> +1 to GN's explaination
GN015: Wants to make sure to get the right understanding on what we all want to express. If it targets a comprehensive set of provisions for what technologies, the provisions are written to be as widely applicable as possible.
<bbailey9> +1
<GreggVan> +1 !
<Ben_Tillyer> +1
<eloisa> +1
Rachael: Yes, that is my understanding and what we are trying to express. Asks for people to +1, etc.
<LoriO> +1
<ShawnT> +1
<stevef> 0
<Makoto_U> +1
<AWK> +1 (and 0)
<Monica> +1
<laura> +1
<Charu> +1
<Heather> +1
<stevekerr> +1
<Glenda> +1
<joryc> +1
<tayef> +1
<alastairc> +1, and to note, this is text that goes into the intro of WCAG3, so is directly useful!
<LenB> +1
<Detlev> +1 bordering on 0
<CClaire> +1
<kirkwood> I’m having difficulty with ai generated content
<GN015> +0.5
<scott> +1 / 0
Rachael: Sees no objections.
kirkwood: We talk about AI generated content here and not human generated content. It's kind of weird that this is the only part that we're talking about.
<Charles> +1
<Glenda> Shadi, what about swapping the word “inform” with “The guidelines are also applicable to”
<Jon_Avila> +1 although I think PDF is sometimes web content as it's delivered via https
<stevef> +1 to Glenda
<alastairc> Glenda - we have a third-rail situation with UAAG / ATAG, and not writing directly to those...
Rachael: The topic has come up before. Open to including something; wants people's thoughts on it.
<joryc> Content is content, who or what created it doesn't matter. We don't track if someone used MS Word or Google Docs in writing
GreggVan: We might say AI-mediated interaction might be better than generated content.
<Zakim> GreggVan, you wanted to say "AI mediated interaction"
Rachael: Does anyone have an alternate suggestion or have concerns?
<stevef> +1 to joryc
joryc: Why do we need to have anything in there at all?
<laura> +1 to remove the AI bit
<GreggVan> +1 to jory
<AWK> +1 to JoryC. Policy makers can apply WCAG 3 to content whether generated by ai once or dynamically
Rachael: Recognizes support in IRC, asks to try to wrap up this conversation.
GN015: Sometimes AI generates the content presented to the user, and it shows to the user should also be accessible.
<Zakim> GreggVan, you wanted to say "all audio"
Glenda: Similar to what GN105, I'm not thinking AI as a content generator necessarily, I'm thinking of it as an interface itself for users. We don't know what it will look like a year or two from now.
<kirkwood> ai delivered ?
<Zakim> bbailey, you wanted to say if you don't explicitly address AI, there will be many question about how WCAG3 applies to AI.
GreggVan: We should delete the generated part of content. Generated by AI should be on there.
bbailey If we don't have anything in there, people are going to keep asking.
<bbailey9> maybe "including but not limited to"?
<alastairc> This section is here for the non-initiated, to give people examples of what is covered... we're speaking to people outside of this group.
<Glenda> I can live with dropping the AI piece in that paragraph
joryc: AI isnt' a platform, it's a computing methodology; it doesn't belong here. It's just content being delivered to the user.
Rachael: We need to note that this needs more work and need to survey it.
<bbailey9> +1 for distinction between "types" and examples
GreggVan: Dynamic Interact Streaming is also not a content type, it's a delivery method.
Rachael: Captured the feedback; moving on due to timing
Rachael: Last question we have is that eight provisions is too much to review in three weeks. How many is reasonable in a three-week time frame. Some subgroups need feedback.
discuss provision surveys
Rachael: what is reasonable and doable?
<AWK> Not too many in 3-4 weeks. Was hard if didn't start until yesterday.
<Zakim> GreggVan, you wanted to say "streaming is also not a content type and to
<alastairc> AWK - would it help your deadline thinking if we did 4 in 2 weeks instead? ;-)
GreggVan: Which ones do you want feedback from first? Suggests to take ongoing feedback so the subgroups get feedback.
Charles: Do we ever close feedback or question for review?
<AWK> alastairc I wasn't the one complaining! :)
<Zakim> bbailey, you wanted to say I would like subgroups offering to be complete
Rachael: No, you can look at these anytime, anywhere. We have targeted reviews to help subgroups get into a rhythm.
Charles
Charles: Indicate that there is a question that unblocks work.
<alastairc> "Flashing provisions update"
bbailey: appreciation for how you phrased the question. I had expected the ACT Rules to reflect the provision. I expected compound and atomic rules, but that's not what i saw with this set.
Rachael: Thanks for the feedback; we'll come back to it.
alastairc: To Charles' comment, use the issues to determine when review is ready to come back again.
giacomo-petri: The survey is a good opportunity to refine. It's a way to keep things moving forward. I think it's helpful to detect blockers or something that needs to be addressed.
<shadi> +1 to giacomo-petri
Rachael: Thank you everyone; please consider that question a little bit more and give feedback to the chairs. We will put this out in some form to get to a consensus, please check your email. Have a great week.