Meeting minutes
Announcements or introductions
alastairc: any announcements or introductions?
… one more week of time differences for non-US participants
… no other announcements from the chairs
alastairc: midpoint on wcag2issues email
<bbailey> https://
Patrick_H_Lauke: you’ve all got one week left to review issues that were sent last week
… just a handful this time
<bbailey> WCAG 2 proposed changes (review by 23 March)
Patrick_H_Lauke: if you have feedback, please share
… before Monday of next week
hdv: quick update on WCAG-EM
… sent out an email a week ago
… looking for feedback as we aim to transition from Draft Note to Note state
… want to make sure we get feedback especially from people who’ve conducted or are involved with evaluations
… we presented about this at CSUN last week
… got great feedback there, which is visible in GitHub comments
… also want feedback from this group
… 1.5 weeks more for this comment period
… after that, we’ll do another call for consensus
alastairc: I got about 30% through and have no feedback yet
Check in on ACT Exercise
<hdv> email requesting feedback: https://
alastairc: check in on ACT exercise
Rachael: just a chance to ask questions
… went over updates last week
… want to see how groups are doing. Any questions or concerns?
<alastairc> Slides from last week: https://
Detlev: doesn’t seem to be clear whether exercise is limited to web stack
… or whether it should cast a wider net. Mobile apps, documents, etc.
… makes a big difference in the approach
… can you clarify?
Rachael: will share a slide that relates to this
… structure in WCAG 3 is Guidelines > [ Assertions, Requirements ] > Technology-specific methods
… there will be a method for mobile, a method for documents
… which will be technology-specific
<alastairc> Slide 10
Rachael: we would like each group to, for each requirement, create one technology-specific ACT style test
… starting with HTML
… but if you want to do a mobile one, you can
… and then use that to refine the requirement text and procedure text
… with as much specificity as possible
… informed by the exercise
… start on slide 15
<LoriO> can someone share the link to the slides?
alastairc: we will focus on more tests than HTML, but we chose HTML to start since it’s familiar
… we’re just looking for between 1 and 3
… the aim is to dig into the wording
… the definitions of things
<Zakim> bbailey, you wanted to ask about slide 10 -- technology agnostic
alastairc: and use that process to update both the test procedure and the actual requirement itself
bbailey: back on slide 10
… where does the test procedure go?
alastairc: immediately beneath Requirements (just updated slide)
GreggVan: Test Procedure is under Requirement, and then ACT style is under technique
… so you’re looking for two kinds of tests?
Rachael: yes
GreggVan: Methods are similar to WCAG 2’s techniques
alastairc: techniques are the most granular thing
GreggVan: I think the ACT style tests should be tagged as “sufficient” or “partial”
… to clarify whether it meets the requirement fully or partially
<Zakim> AWK, you wanted to ask about rule granularity
alastairc: yes, we’ll need to be clear on partial and sufficient— where that actually sits, we’re still working on that
AWK: I’m working on one around speaker identification in the media section
… the procedure for a lot of that is technology-independent
… because it’s just whether the info about who‘s speaking is present
… in, say, the captions file
… my second question is around granularity
… if we’re talking about the provision of captions
alastairc: the test procedure is your top-down “as a user” — what procedure would I use agnostic of technology to determine whether the provision is satisifed
<Zakim> Heather, you wanted to ask about if the list of technologies has been defined
alastairc: the ACT rules are much more granular to dig in on exactly what passes and fails
Heather: is there a definitive list of technologies published?
alastairc: not yet, but that is a topic for later
Top level exceptions (essential, duplicate)
Rachael: please review slides 15 through 19 again
Rachael: we’re going to pivot to a top-level topic of “Exceptions”
… touched on this 5 months ago
… got some pushback
… wanted to come back and talk about it in a broader sense
… see where people stand
… will mainly lean on WCAG 2 to start with
… hope to timebox to 30 minutes
… in WCAG 2, we have a few things that apply more or less universally
… like “Conforming Alternate Version”
… (slide 3)
… if you have a CAT, you conform
… do we want to carry this forward in WCAG 3 as a concept
… we also have a concept of “equivalent”
… “equivalent purpose”, “equivalent information”, etc.
… but we also use it as an exception
… in more recent SC
… such as Target Size
… “if the target is available through an equivalent link or control on the same page”, then it’s a valid exception
… on slide 5
<Detlev> Could someone post the link to the current presentation?
Rachael: we also have “essential”
… “if it were removed, it would fundamentally change the content”
… we use it in 2.2.3 around Timing
Slideset: https://
Rachael: but often we use it as an exception
… in 1.4.5, “a particular presentation of text is essential”
… path-based gestures
… and so on
… the concept of “essential” exceptions
<Detlev> say access denied?
Rachael: question to the group: do we want to carry this forward as well?
<Detlev> says
Rachael: also want to touch on “equivalents”
… (slide 6)
… a map can be controlled by click & scroll, but also by accessible buttons by the side
… so our question today
… do we want to bring these forward to WCAG 3?
GreggVan: I worry some things lend themselves to equivalents or exceptions, and some things don’t
… yes, we should explore it as global, but we should go to each individual item to see if it’s necessary
… it’s very open to abuse
… for example an artist might try to argue that a particular presentation is essential
… so the word “essential” can be misused
… the “equivalent” I’m also a little worried about
… for example, the Target Size exception could be abused
<Charles> i am thrilled by how many of us first ask ‘how can this be abused?’
GreggVan: a big Submit button in the conventional place but that fails target size
<Zakim> hdv, you wanted to comment on a conforming alternate version and 'essential'
hdv: regarding CAT
… I think it would be great to explore that for WCAG 3
… useful concept
… we don’t see it a lot
… most people make their original version conformant
… we did a survey and discovered not many people have used a CAT, but we still think it’s a useful concept
… regarding “essential”
… think it’s helpful
… sure, it’s prone to abuse, but there are genuine use cases
… makes rules much easier to write
<Zakim> alastairc, you wanted to comment on the examples and to also say how we've used methods to explain this
alastairc: wanted to mention about examples
… for “equivalents”
… when I first started using WCAG 2
… I hadn’t really gotten that CAV could be within page
… because it’s written to suggest it’s entirely separate
… but later learned it could be on the same page
… for example a pointer gesture with an equivalent operation
… another example is text embedded in an image, but also included in plain text beneath the image
… for “essential”
… in my subgroup, with flashing and animation
… we’re needing to add an essential exception to everything
… for example, a news conference with lots of flash photography
… it’s unavoidable
… so instead we must warn users about it
… what we have done is add methods for each
<Patrick_H_Lauke> "essential" to me needs to exclude subjective "because the author wanted to do it that way"
<bbailey> +1 that CAV being on-the-same-page is subtle (e.g. mouse-only calendar date picker widget with integrated text-entry option)
alastairc: and that method outlines what we would and would not consider “essential” for that context
Charles: I heard the question as “do we want to bring these 3 concepts forward”
<Patrick_H_Lauke> (had similar discussions around essential exception for orientation ... where "we designed it to only work in landscape" is not a valid essential exception)
Charles: to answer that question, each one has a giant “it depends”
… we’ve just heard a few
<shadi> +1 to it depends
<Patrick_H_Lauke> it depends(tm)
Charles: e.g., the CAV being on the same page
… to hdv’s comment on the original version being the one that conforms
… if the default is the accessible version
… and the CAV is not
… that’s a concept that’s worth preserving
<AWK> https://
Charles: but it defies what we’re currently saying in the definition of CAV
… that’s the concept that I‘m not comfortable persisting
<AWK> You'll never be able to be assured that people arrive at one version or the other
alastairc: we can clarify that
Wilco: I like this idea
… a lot of value
… worth exploring how to refine and do a better job
… often, the default is “the right thing”
… another thing that comes to mind is WCAG 2 doesn’t say the CAV needs to be in the same *language*, which is odd to me
… doesn’t say it needs to be in the same format
<Charles> essentially “non-conforming alternate” is acceptable
Wilco: for example, a video shouldn’t be permitted as conforming alternate
… games on the web are another interesting case
<AWK> conforming alternate version
<AWK> version that
<AWK> conforms at the designated level, and
<AWK> provides all of the same information and functionality in the same human language, and
<Jon_Avila> People sometime want the conforming alternative of an interactive course to be a PDF document.
<Jon_Avila> I agree we need an allowance for an alternative. We also need some allowance for "essential".
Patrick_H_Lauke: more important than whether the CAV is on the same page is to have a higher-level statement
… product-wide or site-wide
<bbailey> Definition for CAV does include "in the same human language"
<bbailey> https://
Patrick_H_Lauke: a user must be able to get to the same or equivalent content and achieve the same result
… certain functionality that’s provided
… they can get to the same end result
… then it’s irrelevant whether it’s on exactly the same page or a separate site
<Charles> +1 to achieve the same result
Patrick_H_Lauke: having a holistic view of the entire thing you’re assessing
… can any kind of user get to the same end result
… rather than being too specific
… must also reconcile that it needs to be “as prominent”, but that gets tricky
shadi: agree with Patrick_H_Lauke
<giacomo-petri> +1 to patrick
shadi: CAV came from times when SVG and other technologies weren’t yet available
… so you’d have a second page to describe complex information
… today we also have “modes of operation”, such as dark mode
… but yes, it depends
… will need deep dives on a case-by-case basis
… in a complex system with components, one thing on its own might not meet requirements, but the *whole* thing collectively might meet requirements
<Patrick_H_Lauke> i did like alastc's earlier take that "essential" should be more along the lines of "unavoidable" (due to technical limitations, or the intrinsic nature of a particular content/functionality/experience)
<Zakim> alastairc, you wanted to comment on customisation vs the original
<Patrick_H_Lauke> +1 to a more generalised "achieving the same result"
alastairc: on the customization bit that Charles raised
… noted that the default thing *should* be the accessible one
<Patrick_H_Lauke> "default needs to be accessible" won't fly with content authors though
<Zakim> Heather, you wanted to mention conforming equivalent use case: export functionality of different file types
Heather: one use case is exporting payroll data from enterprise software
… there may be 4 or 5 export options
… right now, you only need to make *one* of those accessible
… which one would be the default? is my question
<Patrick_H_Lauke> the whole reason why there might be alternatives/customisations is often that the "default" is the "sexy/fancy/etc" one that marketing/CEOs/designers want to provide
Heather: and how do you communicate to the user which versions are and are not accessible
<Ben_Tillyer> +1 to communication of which version is accessible to user
<Patrick_H_Lauke> and/or the one that works "for the majority of users"
<Zakim> Rachael, you wanted to say I would like this to be more visible
Rachael: chair hat off
… CAV is very powerful in WCAG 2
… and not very visible
… toward the bottom of the document
… I would like to make it more visible
… perhaps there’s a candidate here for an assertion
AWK: agree with Rachael
… do think it‘s worth reading closely the definition of CAV
… it does in fact say you need to have the same human language
… and a whole section on reaching the conforming version from the non-conforming version, and vice versa
… do think it’s an important concept for us to have
… will always be new technologies
… augmented reality, for example
… we’d probably need a CAV
<shadi> +1
<Wilco> /me My bad about same language. I stand corrected. Thanks AWK!
<Rachael> Slide deck for March 17 https://
Charles: prominence is subjective
… for things like equivalent purpose
<Patrick_H_Lauke> yes t'was me
Charles: target size, for example
… 2 components that do the same thing on the same page, 1 meets target size, the other doesn’t
<AWK> @rachael deck not shared
Charles: but the one that fails actually passes because of the other one
… instead, how about a concept of “number of instances”
… that might be a better mark than prominence
<Zakim> Jennie_Delisi, you wanted to discuss use case example for employee and supervisor
Jennie_Delisi: one use case that we often encounter where we have to discuss this is if an application is used to train truck drivers or snow plow drivers
… but the supervisor is not able to have all their senses employed to do the application
… but they don’t actually do that job
<bbailey> @Wilco -- it's problematic that it is easy to overlook the "same language" requirement (and other details)
Jennie_Delisi: e.g., a supervisor can be blind and not drive a snow plow, but manage snow plow drivers
… if a supervisor has a performance issue that they need to evaluate based on training of snow plow drivers
… equivalent use could be in a transcript form, but it might not be equivalent *enough* to determine essential duties
<Charles> so, “to whom is it equivalent?”
Jennie_Delisi: just because the person is not the end user that is imagined, that doesn’t mean that the equivalent use case can be scoped in a similar way
Patrick_H_Lauke: it could also be this idea of alternatives
… “version” is a bit loaded
… in contrast to the default
… the idea that the default should be the one that’s always accessible is idealistic
… but in reality the default often targets the “majority” of users and is optimized for that
… and the alternative is presented for “everyone else”
… instead of “version”, could we riff on the idea of “modality” instead
… different modalities that serve different user needs
<shadi> +1 to exploring concept of "modality"
Patrick_H_Lauke: e.g., things that can adapt to different user needs
<shadi> +1 to adaptability too
Rachael: we’ve captured a number of ideas from this discussion
… need to add “modality” to that list
… next steps
… will put these up on GitHub for discussion
… and draft Google Doc for async collaboration
… and then bring back in a few weeks for further discussion
Assumption of user agents
Rachael: set up a subgroup if necessary
… but hope to avoid that, for efficiency
… will send out an email with links
alastairc: we’ve discussed this topic a few times
… (slide 9)
… in WCAG 2, we did assume there is a user agent
… things like text spacing
… basically assume a browser
… and that the user could make adjustments to visual text attributes
… but regulators have now applied WCAG 2 in places with do *not* include a user agent
… and WCAG 3 aims to be more widely applicable
… so it’s a widening of scope
… still assuming digital interfaces
… not trying to get into hardware
… still assuming a platform underneath, just not assuming a user agent
… that’s the background
<Patrick_H_Lauke> platform: either the user agent (when web content in a browser) or OS (when a native application)
alastairc: a few examples
… (slide 10)
… keyboard operable doesn’t necessarily mean there’s a keyboard
… pointer input is another
<AWK> +1 to Patrick's suggestion. User agent is broad enough that it means this anyway "any software that retrieves and presents web content for users"
alastairc: hue not relied on
… (slide 11)
… in WCAG 3, we do have requirements currently where user agents are assumed
<Patrick_H_Lauke> AWK problem is "user agent" in W3C web standards parlance is usually "browser"
alastairc: default focus indicator, for example
… (slide 12)
… there are some things where it will be straightforward to use “applies when”
… to say “one or more platforms in a11y support set” when there *is* a user agent
… need to think about when there isn’t a user agent
<Patrick_H_Lauke> afraid i need to drop, but i'll throw in a sideway: Point of Sale (POS), or even trying to evaluate actual OSs themselves
<Patrick_H_Lauke> closed systems
alastairc: even for this example, we can narrow it down
… (slide 13)
<Detlev> Has a working link to the current presentation Benn posted 8I was kicked out of IRC). The last link leads to "access denied"
<AWK> Patrick_H_Lauke sure, and the UA def doesn't address native mobile apps since references "web content"
alastairc: question to the group: think about subgroup's provisions and think about examples of where generalisation is tricky
alastairc: or are there requirements missing because we assumed user agents?
<Zakim> Rachael, you wanted to speak to Patrick's points
alastairc: and maybe there are other strategies for generalisations
Rachael: Patrick asked about evaluating POS systems
Charles: not sure if this came up before, but do we need to update the definition of user agents now that there are “agentic” user agents that apply heuristics differently?
<Zakim> bbailey, you wanted to mention that evaluating POS requires access to source code
Charles: for instance if I use a browser based on past behaviour vs based on standards built on standards
<Jon_Avila> It seems like if we want to cover platforms themselves - we'd need to have additional requirements for platform.
bbailey: re evaluating POS… one of the unwritten assumptions in WCAG is that the auditor can work from source code… without priviliged access. Are we aiming for the same in WCAG 3?
GreggVan: interesting question re user agents… we need to divide accessibility support into two categories: browser support and AT support. Reasons include AT support is trickier, not everyone can afford it and can't always install it on public computers.
<Jon_Avila> For closed functionality - standards such as EN301549 revert to testing speech output, etc. rather than programmatically availability of information.
GreggVan: if we divide between browser supported and AT supported, we can solve the problem of the user agent
<Frankie> +1 to Greg's point about public computer usage. Forcing users to download AT for accessibility prevents access to a large percentage of disabled folks living in poverty (which is common around the world) who can't afford their own devices.
GreggVan: this way, when common, ordinary browsers become smart browsers, fewer requirements will be needed
<alastairc> q/
<Zakim> alastairc, you wanted to comment on agentive user-agents and to comment on testing without source code accesss
alastairc: re agentic user agents… I don't think that's a big problem for us. If you're using an agentic user agent, the interface of it matters… but if it is doing things for you that kind of falls out of scope, as the user is no longer interacting, it's the agent doing that interacting
<Zakim> Rachael, you wanted to react to alastairc
steve_faulkner: my concern with Gregg's comment about browser vs AT distinction… where do non-browser UIs go? It sounds more tech agnostic than WCAG 2
alastairc: do you mean more tech specific?
steve_faulkner: yes, and defining scope to browsers and AT, but that's not the use case we're working towards. WCAG 2 has been used for non web interfaces. So need to account for that and accept that as a reality
GreggVan: tech agnostic is the root requirement… if this is something viewed in a browser and the browser would take care itself… if all of the major browser become intelligent user agents and all have a feature in them that look at any page and mark up all the headings
GreggVan: but in cases like a kiosk it's not going to be a UA for the user, or a smart browser
GreggVan: so it depends on the type of product how much it affects it
<Ben_Tillyer> GreggVan - Are you saying that you can't assume users are using a certain AT because of cost/access, but you want to assume that they are using a certain browser?
Charles: based on Gregg's suggestion of separating personal and other agentic AI… trying to think of alastairc's question about what might be tricky to generalise… if an agent is aware of what causes me harm, from learning that behaviour, it would then be capable of removing that harm on my behalf without me having to encounter it
<Zakim> alastairc, you wanted to comment on differences between platform, AT and browsers and to
Charles: should we have to account for that?
<GreggVan> Ben_Tillyer - I am saying that authors can rely only on things they know the user will have available to them when they
<GreggVan> Ben_Tillyer - I am saying that authors can rely only on things they know the user will have available to them when they "view" the content/software/app
alastairc: our subgroup talked about pseudomotion, animation and flashing etc… a method you can use is a user agent configuration that might prevent flashing, as one example. If that had sufficient support, it would meet that requirement. The requirement is agnostic, but within it there are multiple ways to meet it
alastairc: we do have a platform definition… there are some features that are part of the platform
<Zakim> Rachael, you wanted to say its less about it being a browser than being freely available
alastairc: platform AT and browsers are potentially what we need to differentiate
Rachael: chair hat off… I think the lines are going to get increasingly blurry between browser, AT, UA settings, etc. Especially when new interfaces come up. So thinking about a different way of categorising will be useful
Rachael: I think we need to be less tech specific and better at creating parameters and guidelines
<GreggVan> s /not things/not layers/
<Ben_Tillyer> GreggVan - At what point would you say that an author would 'know' what they would they have access to a certain browser feature? E.g. 'only' 97.25% of browsers in use across the world support SVG, is that high enough? (source: https://
<Charles> so user agents themselves are becoming technology agnostic
steve_faulkner: to follow up from Gregg's initial comment… when talking about kiosks, we still have the situation where the kiosk is usually built as a UI that has all sorts of properties… they tend to make it accessible but also add a screenreader, available to user when they need it
steve_faulkner: I am not sure if that is an issue. “JAWS for kiosks” exists… but doesn't have the same functionality, eg buttons not announced as buttons
steve_faulkner: even if a 'smart browser' is used, we still need to test things like headings
steve_faulkner: we still need to know if it is reliable. Given the issues with LLMs, I'm not very optimistic.
alastairc: I don't want to go into the capabilities… but I do want to make sure we're as future proof as we can
<Zakim> GreggVan, you wanted to say -- we need to explore the whole stack and talk about functions - not things. FUnctions will be at all levels
GreggVan: what Steve said on testing is key. Whenever support relies on AT or browsers or OS… it doesn't matter, we have to test that it does work.
GreggVan: if you test and know AT can reliably do that, the author is off the book. _If_ they can assume the user will have access to the AT
<Charles> “until browsers” was baked into WCAG 1
GreggVan: that also handles the case when there is no browser
GreggVan: can't rely on something that isn't there
<Rachael> +1 to avoiding assuming free AI
<Frankie> +1 to Scott's point. Subscription models are the market and disabled folks are statistically more economically disadvantaged than non-disabled people.
scott: re notion that we can't assume people have AT because it costs money, as a pessimistic individual, I want to say it's also important to note that AI is expensive and may not always be available for free
<hdv> +1 to Scott
<Zakim> GreggVan, you wanted to say -- free at and local ai
<kenneth> that's a really heavy assumption that everyone everywhere in the world has access to high-end / new hardware... especially when the price of hardware is skyrocketing _because of_ speculative datacenter building _for AI_
GreggVan: if it's local it may be free
<hdv> +1 kenneth
alastairc: if there's any thoughts folks have, do let us know, we'll probably talk about this more later
Accessibility Support Set
alastairc: let's move on to the next topic
alastairc: one of the key problems we have to consider is, how to evaluators know that the results of an evaluation, or authors of what they authored, correspond with the experience of real people and support of their tools
alastairc: in WCAG 2 we have the concept of systems that are widely distributed
alastair: in WCAG 3 we've looked at various aspects of this. One is that we can't rely on user agents to always work with any particular feature
alastairc: also, capabilities can vary by region, for instance in Japanese vs English screenreaders
alastairc: previously we decided support would be at feature level, not general technology level
<Ben_Tillyer> local AI does not mean free AI. Nice paper that's worth a read: https://
alastairc: at our baseline we want authors to be able to assume that methods we provide are accessibility supported
alastairc: example support sets include the one at the UK governmen and axe-core
alastairc: the support sets may get defined in a community group, we want this to be an informative document that is updateable
GreggVan: we should differentiate between browser and AT support
GreggVan: one can apply at provision level, another at the Technique level. Can apply in different places
GreggVan: I agree that there are differences in features between geographical areas
GreggVan: we can't say in our document that 'in order to test this you have to use this informative doc'; so would say we can include when something is a 'common browser'.
<Charles> +1 to characteristics over names
<Zakim> alastairc, you wanted to comment on closed environments having own support sets and to comment on having our own support set, wouldn't rely on external org
GreggVan: if we describe characteristics we can avoid product names
alastairc: if you are testing something very specific, like a kiosk, you would come up with your own accessibility support set… and probably your own techniques too as we don't have any for that
<GreggVan> +1 to alastairs comment about not just region. It would be scope of application. It could be regions -- or if the content is only used within a company - one could rely on anything provided to everyone at that company.
<Charles> so is this default support set more closely resemble the implementation report?
kevin: re Gregg's point… my understanding of this is that these are about when a method works, so we're not referring to the methods in a normative sense. we do that in things like Baseline as well, it has a similar challenge as to what we are talking about
alastairc: Baseline do have the advantage that the people working on the browsers are W3C members
GreggVan: if we mention it as part of conformance it becomes normative
GreggVan: for the simple reason that companies rely on it
<GreggVan> +1
alastairc: where we define accessibility supports sets normatively… we can include 'these are the factors' and examples
<Zakim> alastairc, you wanted to comment on normative - informative
hdv: you can absolutely give non normative examples to go with normative text, it is not so black and white as GreggVan sketched
Charles: what I'm hearing… the conformance requirement is that evaluators have an accessibility support set, but we're not recommending what's in it
alastairc: it's less an implementation report in the sense as the ones we provided with WCAG 2.*
alastairc: this is more part of the conformance claim process
alastairc: next question is: what are our criteria for an accessibility supports set?
alastairc: we need to expand our thinking a bit from before
alastairc: and think about what is built into the platforms
alastairc: what should we include and why?
GreggVan: cost availability and usage
GreggVan: if nobody uses the AT, you can't rely on it
<Zakim> alastairc, you wanted to comment on cost and platforms
alastairc: how do we consider cost given that if you buy a particular computer and it may be installed by default, there's some things built into Android and iOS
alastairc: but then if the device you're buying is more expensive, is that a problem
Charles: if usage is one of the criteria, what is a reliable source and how do we prove it is a reliable source? For instance, the WebAIM screenreader survey
Ben_Tillyer: we have to be careful with numbers of users and availability… it may exclude folks with a complex or rare disability
Francis_Storr: probably want to consider corporate environment as well
alastairc: probably a solved problem with our approach
Heather: from the usage perspective… your usage in one part of the world may be different in one part of the world is different than another part of the world
<Charles> and who bears that cost matters
GreggVan: even things we think are free or near free can be expensive
GreggVan: re availability, we need to think about regions
GreggVan: also depends on what users have available, if the library computer only has one browser that can't be changed, other browsers don't matter
GreggVan: we have to be careful
scott: re the topic of usage: availability of AT or features within a user agent that are specifically for people with disabilities, I'd like it if that could be given some weight.
scott: there are some features that have been added to different user agents or tools, where primary focus is to help people with disabilities
<Ben_Tillyer> Extra thought: I wouldn't want to support a document that could be used by authors to tell users that they are using the "wrong" software
scott: but because there are no usage counts behind them, they aren't considered widely used
<hdv> +1, what's being measured != what really matters
Assertions questions reminder https://docs.google.com/presentation/d/1qWuFM3fFgC_e1Jik05Os11O0Rl86HLDXu9dolwyWWtc/edit
Rachael: if you were not here last time: we discussed assertions. If you are in a company where you can talk to someone about assertions, we'd love that. we want to make sure they are going to be useful in WCAG 3
Rachael: we'll get back to this in April and May again
Rachael: reach out to chairs if you have questions
alastairc: thank you
<Ben_Tillyer> Thanks all
alastairc: we'll come back to these topics at a later call