Meeting minutes
alastairc: There's going to be overlap between what we discussed Tuesday and today, but this will also be about who's going to take on particular issues.
Internationalisation proposals
mbgower: Suggest a sub-item for WCAG 3 - how to feed back to WCAG 3 from WCAG 2 open issues; how to scrutinize and triage our 500 issues and however many open PRs
alastairc: On Tues we had some discussions RE internationalization proposals and some other normative things
… there was some discussion about how to handle backwards compatibility, not much came out of that other than taking it on a case-by-case basis
… wasn't entirely sure whether it requires new SCs or can be handled in e.g. new techniques
… can things be done editorially, or via errata, or via informative docs, can automatically be picked up by EN 301 549
… but some people are convinced normative change is needed
… Non-normative work can continue as it currently does right now in the backlog TF
… RE whether or not to allow normative changes in a new version, there was desire to see a list of the planned changes
… I think there was enough impetus from the i18n changes that we will have enough justification for a new version
… maybe we can include some kind of list not in the charter but to the side of it
… Examples of updates: i18n, contrast algorithm, making descriptions RE audio description and/or timing adjustable, remedy missing essential exceptions
mbgower: RE avenues for changes, I've been thinking we tend to get stuck on trying to solve the problem as we're talking about it, i.e. craft the wording that will resolve this
… in some cases, just describing the state of the SC can be useful
… e.g. reflow, it's easy to describe some of the problems
… not an avenue of change, but rather an avenue of identification
… my interpretation of what's happening with WCAG 3 was it is attempting to identify then revamp
… it wouldn't be bad if we could potentially identify some of those things and identify what's wrong with them between now and when 3 comes out
… with WCAG 2 we've been largely chasing what the SC is, rather than what can be done with it
… if we can get agreement on what we want to have covered, then we can work on crafting how to cover it in normative language
<Zakim> mbgower, you wanted to say I think trying to summarize state of SC, not solve, as first step
alastairc: I think maybe we talk about that within the scope of the ones we wanted to dig into today
… RE internationalization, there was a proposal from Murata-san, for ruby annotations (i.e. the blue smaller text next to the larger black text)
… there can be varying levels of complexity, can configure whether it is on/off or how much
… generally HTML would be able to pass the requirement. Historically PDF has not been able to pass it as of 10 years ago, but now it can be done
Murata-san: A lot of people in Japan think that if a PDF document contains ruby, it is not accessible. But now some PDF documents which have correct accessibility trees and ruby roles can be used for text-to-speech. But most PDFs with ruby cannot.
… goal of this SC is to encourage the usage of correct mechanisms, and move away from print-only PDF which is not accessible
alastairc: My question to the group is, what is the best way to approach this issue?
giacomo-petri: As you mentioned previously, I'm not sure why it can't be covered by 1.3.1/1.3.2, it's true that it is optional, but also basically popups are treated as optional
… you have to ensure that the info & relationship is clear (1.3.1), and maybe we have a paragraph in the Understanding document to clarify
… in meaningful sequence (1.3.2) maybe we explain that ruby cannot be read by itself, but needs to be read in meaningful sequence in context of the associated words
<Zakim> mbgower, you wanted to say add a new issue on this in github
mbgower: I'm not suggesting kicking the can down the road, but I think the most logical way to pursue this is to create a new issue with the proposal, and then it goes through the TF process. If we're going to do this live on the call, that's fine, but this can be considered a draft
Murata-san: I attended @@1 IG this morning; they use @@2 which has exactly the same problem
… @@3 has the same problem, and appears free from restrictions of testable requirements. These can be concretely imposed and implemented by software.
… If this is only in the informative document, then this is not in the requirement, and is not a regulatory issue - not enforceable.
<Patrick_H_Lauke> +1 requirements should never be just in understanding/non-normative
<Zakim> alastairc, you wanted to comment on advantage of doing a technique + understanding
alastairc: There is an advantage to doing it in the Understanding document, in that it applies probably from WCAG 2.0 onwards. It is coming under something general, but it would have the same force, just depending on level (A, AA, AAA)
… because it's something that WCAG in general hasn't spoken about very much, this is something that could be done with techniques if we hang it under a A/AA SC
<Zakim> mbgower, you wanted to say this seems closer to 3.1.6 Pronunciation and 3.1.4 Abbreviations
alastairc: it would be as enforceable as anything else there
mbgower: I would like to try restating the problem, to make sure I'm understanding it. I'm thinking it may be pronunciation or abbreviations
<kevin> +1 to Technique being enforceable conformance failure
<Patrick_H_Lauke> if the technique only shows how the normative wording of the SC also applies/emerges in situations that were not obvious, then yes "just" doing a technique would be ok
mbgower: [ distinguishes kanji / kana, and how the small blue characters are phonetic descriptions ]
… it's providing pronunciation, roughly equivalent to an acronym or abbreviation?
<alastairc> I think there was a point that sometimes these characters can be abused to say other things, but that would be another type of SC.
<shawn> +1 that adding clarification and specifics in understanding and techniques to A or AA SC(s) then applies for WCAG 2.1 and 2.2 (rather then waiting for WCAG 2.3 for a new SC)
Murata-san: I'm trying to write a technical note about TTS and ruby, and the internationalization WG agreed on a technical note. That note discusses the taxonomy of ruby, and phonetics is just one aspect
… e.g. "enemy" having "friend" as ruby
… and now Chinese people are mimicking this
alastairc: That sounds like people are essentially misusing it to say other things?
Murata-san: Yes, it could be considered an abuse, but it is extremely common
alastairc: So there could be a distinction between it being provided and accurate?
<mbgower> https://
Murata-san: There has been discussion over whether HTML should have another attribute to distinguish phonetic vs. other uses of ruby, but there will be tons of documents that do not have the new attribute
<mbgower> https://
<mbgower> The language of both of those SC seem highly relevant to me, here.
<alastairc> q/
Murata-san: I am reluctant to introduce a new attribute. I'd like to see it solved by AI, but people suggest that it is not currently feasible with AI
alastairc: This is reminding me that in COGA, some people with cognitive disabilities would have a browser plugin to convert icons to text to help them understand
kevin: WAI-Adapt symbols
alastairc: I think that was hanging under Input purpose and identify purpose
<Zakim> mbgower, you wanted to say a major shortcoming of <abbr> is that it has no attributes
mbgower: I pasted in the links to abbreviations and pronunciations, can we look at the language of those?
… the mechanism provided through the ruby interface is a mechanism to expand the abbreviation
… pronunciation is about avoiding ambiguity
… there's no requirement of programmatic association
… that's kind of how I'm seeing the problem with English, and then it's much more specific in Japanese
alastairc: I'm not convinced either of those would apply - they're not necessarily expanded forms, they're not necessarily pronunciation
… certainly the proposal was more along the lines of programmatically determinable relationship
… the only other thing might be the level A technique, can't remember the number, under 2.0 that would apply to ISO versions
<MURATA> +1
Ken: I think usage of ruby is to clarify, although it has a pronunciation aspect
… I don't see abbreviation fitting in here
<MURATA> Japanese ruby provide no info about accent.
<Zakim> kevin, you wanted to ask if we don't already have this in H62
<kevin> https://
<mbgower> To clarify, I wasn't saying that 1.3.6 and 1.3.8 cover this. I'm saying that 1.3.1 doesn't entirely fit
kevin: we've got Technique H62, which discusses usage of ruby element in HTML. It's not the same as abbreviation; the structure is different and creates an appropriate association. That's under pronunciation, so it doesn't necessarily cover relationships
… it also doesn't talk about PDF as a technique
… Given you can make a technique a formal conformance failure, as Alastair was alluding to, would it not be an approach to create a technique that talks about the technical aspects of ruby presentation in PDF, and have that within 1.3.1 Info and relationships
… and then have a failure point, that if you don't have the proper association, then it is a failure
<MURATA> FYI: https://
<alastairc> https://
kevin: you could go further and have an HTML failure under Info and relationships as well
… I wonder if that allows us to effectively use the SC we've got, create clear conformance failure points using techniques, and highlight how those need to be done properly
<mbgower> +1 I'm all for seeing if a hybrid approach like kevin is mentioning has merit. that's where i was trying to go
kevin: There could be something wrong in my relatively simple thinking, but I'm wondering if we can use the tools we already have available to achieve what we want?
alastairc: It could be, just nobody has tried that before
giacomo-petri: Echoing what Kevin said, I understand Murata-san's thought that having a SC will make everything clear
… it can already be covered / failed under existing SC
<Ben_Till1> +1 to that reading
Murata-san: Are you saying the Understanding document can clarify what is normative?
kevin: It's not the understanding document, you can create a very specific failure technique to outline what fails within the normative material.
… so RE what you said earlier, that it's not clear it would be a normative failure, this would be making that clear, so this is a powerful tool to promote that sort of thing.
Murata-san: I didn't know that, thanks.
Makoto_U: RE SC 1.3.1 and 1.3.2 covering this issue, and Mike mentioning 3.1.4 and 3.1.6 being similar
… as I mentioned at the breakout session about non-latin scripts, in WCAG 2.0, Watanabe-san, I, and others, were Japanese representatives, we tried to get ruby covered in WCAG 2.0 as a means to read complex kanji characters
… we made a proposal
… 3.1.4 and 3.1.6 are at level AAA. Concern is it won't be enforceable / won't change the situation, as many regulators target AA
Murata-san: Japanese publishers even said AA is too much, they only wanted to commit to A
kevin: 1.3.1 is A, and this fits in 1.3.1, so it fits in level A
… namely the part of making it programmatically related
… it doesn't solve the problems of people misusing it and the quality is incorrect
… but certainly the programmatic relationship can be level A
Murata-san: And you are saying we can pose a conformance requirement via a failure technique and it will be honored by implementations? Sounds reasonable to me
kevin: The whole thing follows through the TF process; I don't want to hijack Mike, Bruce, and Alastair
… it's not breaking anything, we know it fits with all of the information, it's just providing clarification
<Zakim> mbgower, you wanted to say that this information is only exposed through the user agent, though, right? This is not visible in a browser and to and to say will the katakana appear in a user agent? Is the ruby reader a browser or AT?
mbgower: I want to see if I understand the kind of circular problem.
… I do not believe that web browsers will display anything but the Kanji. Is the ruby reader considered AT?
<Patrick_H_Lauke> so as initial action: create a technique under 1.3.1 (A) for programmatic association - provided that the ruby annotation IS visible in browser/user agent
mbgower: if we think it's always there, we can put it under 1.3.1
Ben_Till1: One thing I hadn't seen this week was a code example, so just during this meeting I looked at the HTML spec, and put something together. Tried to make a PDF as well but didn't have enough time
… so I followed the Ruby HTML notation where we have base characters and smaller symbols. Need to zoom in on this example to show it well.
… what I wanted to do is look in the accessibility tree. You can see that each character is in a ruby tag
<Zakim> Ben_Till, you wanted to react to mbgower
Ben_Till1: wanted to show this because it helped me get my head around it in HTML. I'll try to use Adobe DC to convert to PDF from HTML, and put a document together
<mbgower> Thanks, so the katakana is in there by default, so it seems to fall under 1.3.1, then.
<Zakim> alastairc, you wanted to comment on enforcement and to also say that just because it isn't shown by default, it is authored, so it's like a pop-up being associated with it's trigger.
alastairc: On Tuesday, AWK put an example of doing it in PDF
… RE content enforcement, I wanted to mention that if we added a new failure technique to fail improperly-associated ruby techniques, that becomes as enforceable as anything else, but we don't do the enforcement, that would be up to other organizations
<Ben_Till1> Link 1: codepen editor view https://
alastairc: RE Mike's comment on it not appearing by default, I don't think that's a problem, there are other similar situations for other technologies
Murata-san: By default ruby is displayed. I'm not aware of PDF viewers that allow them to be hidden. In HTML it's up to the stylesheet.
… For some people with visual disabilities, ruby is problematic and they want to hide them. Different users may always want it displayed because they have trouble reading kanji.
<Patrick_H_Lauke> think there's a lot of different, interrelated aspects here (even going into UAAG, HTML)
Ken: Are people keeping track of all new techniques as they are added? Do they review their sites accordingly?
<Zakim> mbgower, you wanted to say I'm satisfied we can cover as a failure of 1.3.1. The additional considerations are another thing
mbgower: We're not capable of stopping the presses for anyone :)
… some of the things Murata-san is talking about go beyond the programmatic association. I'd like to identify what those things are and make sure that each of them can fit into some part of this
… if they can't, that's definitely something we want to tackle in WCAG 3
<Patrick_H_Lauke> programmatic association, "accuracy" of information in the ruby annotations, how user agents/readers actually expose these (by default, as an option, etc)
mbgower: e.g. abilities to manipulate, maybe that's controlled by things like reflow or text spacing, but I'm not convinced it is
giacomo-petri: RE how to notify people about changes, perhaps we can add something to the Understanding document. Maybe we can add something about CJK languages clarifying the purpose and referencing relevant techniques
<Ben_Till1> +1
giacomo-petri: I strongly feel that people involved in accessibility topics should be monitoring the informative docs, because otherwise we are wasting time.
<Zakim> shawn, you wanted to say we have ways to make it happen :)
giacomo-petri: I think it's fair to say that, hey, take a look at the informative docs if you have doubts or are unsure, while evaluating site accessibility
shawn: We do have ways that we can share information and promote/push information
<Patrick_H_Lauke> maybe we should collate a list of "changes made to non-normative documents" based on git logs to periodically push
shawn: whether it's this or other substantial updates, it would be good to use WAI announcements and messaging to push updates to the community
… piggybacking off of Shawn, I don't think we should go looking for problems and things for us to do, our main job is to create the standard and make the details of what passes/fails as clear as possible
… making sure the community knows about it can be up to myriad other people
<Zakim> mbgower, you wanted to say maybe we should surface failure techniques for obviously
<Patrick_H_Lauke> education and outreach... ;)
shawn: making a good standard is already hard enough :)
mbgower: RE kenneth, maybe one thing we need to think on is the importance of failure techniques. They're still informative, but they have a lot more weight than anything else, because you are actually showing a failure.
<shawn> [ that's what I was gonna say, Patrick -- even without a WG, that's part of WAI work ]
mbgower: they can't go into our errata, but maybe it makes sense for us to have a clearer way of surfacing new failure techniques especially.
<alastairc> q/
mbgower: for one thing, they have a knock-on effect to ACT which I don't think the sufficient techniques do as much
… maybe the co-facilitators can work on that
alastairc: Failure techniques are quite rare; there's not nearly as many because it's rarer to be able to say that in every single case it's a failure.
… this could be one of the new rare failure techniques.
… I'm getting the sense that everyone's on board with this being a reasonable approach
alastairc: can someone volunteer to get this in, and the slide is available if that helps
<Zakim> kenneth, you wanted to ask scribe stand-in for a few minutes
Mike: I'll open the issue
… I'll get your id Murata san I'll assign you to it
… Ad these comments to the existing issue and we'll open additional ones
Murata: I'll have to check, but I'll add back if needed
<shawn> [ Shawn points mbgower to w3c/
Text spacing
Alastair: Discussion on Tuesday morning
… Murata was proposing informative. But we may end up needing something normative
… For same text spacing at the moment there have exception that if it doesn't apply to that script there is no requirement
<Patrick_H_Lauke> https://
Alastair: NOt optimal, because there might be different properties for which it applies
<Patrick_H_Lauke> "Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.
Alastair: This is mainly to make it testable
… We can't clarify the script type without inserting a big table
<Patrick_H_Lauke> (this SC is a good example of a ... well-meaning, but badly written - arguably - SC)
Alastair: In WCAG3 we break these out, we have five specific languages
<mbgower> I have created a brief issue to capture the ruby issue. I can add in additional information in the description w3c/
Alastair: The other question -- These shouldn't be just the baseline of how scripts should be laid out
… It's also about how to specify boundaries
<Zakim> kenneth, you wanted to volunteer to pick scribing back up
<Patrick_H_Lauke> +1 accessibility recommendations (the minimum that a user can modify things to) rather than baseline recommendations
alastairc: Is that a reasonable summary, that you were looking for some informative changes to expand on the SC?
Murata-san: Ideally in the main document, there should be a mechanism for introducing different requirements depending on the natural language used
<Patrick_H_Lauke> changing this fundamentally to include different languages NORMATIVELY will be a big change
Murata-san: I tried to write down such a thing not using an external registry; but then of course the main document would have to include a lot of restrictions, each value for each language, and the result can become messy, but it is usable
<Patrick_H_Lauke> though if for english/latin languages the values are the same as the current metrics, at least it'd be backwards-compatible
Murata-san: that is one possibility. Another possibility is to introduce an external registry, and from that we invoke different normative documents depending on the value
… this in theory works nice, but in many cases, registries fail in certain standardization. People don't add so many entries in registries, and very often stop maintaining them.
… so while in theory registries are good, in practice they don't work very well. I know W3C has their own strict procedure for creating registries; creating/maintaining is not easy
… so registries come across as discouraged
kevin: I think on paper, a registry is a good mechanism to address this problem. I don't know enough about how they've been used in W3C in the past or now, to work out whether or not that is a good way, or may have the same problems as we've seen in ISO.
… one advantage of a registry, is if we start populating a registry for WCAG 2, it's equally applicable for WCAG 3.
… I will look into it a bit more.
alastairc: I think there's 2 problems. One is this mechanism that we have a whole plethora of requirements depending on language/script
… the second problem is actually having people to fill in the values. It's not only people who are experts in the language, it's that and knowing what values will be appropriate for accessibility purpose.
… having the necessary research is very helpful; but appropriate values for each language are likely written _in_ that language
giacomo-petri: If we have that external registry, is the goal to link it from the normative document? Because if we link it from the Understanding, we still have the same problem
<Patrick_H_Lauke> what happens if the registry changes?
alastairc: I think it will require a normative change. Could be "if these values don't apply, then check the registry"
… RE what if the registry changes: I thought registries were essentially normative? So it should be the same as referencing another normative spec
<shawn> [ info on W3C registry https://
nigel: I've done some work on registries. Registry content is not allowed to have normative semantics
Murata-san: Registry is flexible, but can be a backdoor
Murata-san: The whole point of introducing a registry would be to introduce normative semantics
<Patrick_H_Lauke> agree that a registry itself may not contain normative semantics, but if the normative spec points to the registry and "blesses" it by reference....
Ken: Re-iterating a point from Murata-san during the breakout about having select "first-class" language values in spec creates a "second-class" distinction for others in the registry
<Ben_Till1> https://
Ben_Till1: McLeash study involving 480 languages and multiple scripts; I haven't read the study, but am wondering if anyone has, and knows what they say about CJK languages?
<Ben_Till1> https://
<Ben_Till1> "Testing the following pages with the maximum spacing adjustments allowed by
<Ben_Till1> the SC showed no adverse effects for the roughly 480 languages and scripts
<Ben_Till1> y
shawn: I seem to recall something in the low vision task force, that may be useful. I'll dig it up
alastairc: We've still got 2 issues - how to insert it, and how to get the information that would go into such an external link
<nigel> The Process §6.5.5 and §6.5.6 https://
<alastairc> w3c/
alastairc: If no one has any other ideas, I think we've got research to do on registries
<nigel> and "and must not define any requirements on implementations."
alastairc: Murata-san, if you or anyone knows where we can get the information on increased accessibility values, that would also be of interest
<Patrick_H_Lauke> point of order: from my understanding, the mcleish study referenced did NOT cover the "480 different languages". at least the abstract for that study does not seem to suggest that
shawn: That seems like a bit of chicken-and-egg in a good way - if we provide the framework of how we provide the information, then it makes it clear what we're looking for, and may encourage people to help dig up the data we need
alastairc: We've got a few things that I could find for normative updates
… I found 5 (in Slide 8) that definitely seem to need some kind of normative update, due to affecting interpratation, or relating to internationalization
… can the group think of anything else?
Ken: This may require going through the remaining open issue to decide
alastairc: I think there are very few that are labeled Normative, though we may have put some off and said we're not changing it. This may be an opportunity to re-tag some things as Normative, if it's something that could be improved or clarified
<Ben_Till1> Thanks Patrick_H_Lauke - study performed, then testing (by Jim Allan?) followed
alastairc: we're not looking to add new requirements, that would go to WCAG 3. But if it's a clarification on existing, that's what we're looking for.
Patrick_H_Lauke: One of the more pervasive problems, there's a few instances where the SC hand-waves things, "something something clearly labeled as such", and never specifies what "clearly" actually means
alastairc: In the actual SCs, it seems to be all of the media ones
Patrick_H_Lauke: Look for "clearly labeled" or "clearly marked"
alastairc: There are 5 instances of "clearly"
Patrick_H_Lauke: The other was under the statement of partial conformance
<Zakim> mbgower, you wanted to say contrast minimum has some need for qualification (scrolling effect)
alastairc: There was also the issue of some of the 1.2.x including the exception, but others including it if you read down into the definition
mbgower: One thing that springs to mind is contrast minimum and UAs hiding scrollbars.
… some designers are finding a need to clearly indicate when more content is available, e.g. by fading out the text. It's not a truncation, it's just not in view, but without the scrollbar there's no way to tell
… all you have to do is scroll, and all of the information is visible under normal contrast
… I'm not necessarily advocating for it, but it's certainly one way of meeting a need
… it's not clear to me that contrast (minimum) should apply all the time, if they do want to have that as a failure
… this is common practice now, it fails the current language; do we want that? If we agree we don't want that, we can fit that in as an exception. Otherwise we need to make a failure technique and attempt to course-correct
<Zakim> giacomo-petri, you wanted to mention another SC that may require some tweak in the normative portion
<Patrick_H_Lauke> mbgower ... did you have the issue number for that? I'm sure we discussed this on github, but can't seem to find it
giacomo-petri: Another SC that we've talked about in TF meetings is 2.5.3, due to UI components using labels containing images of text
<Patrick_H_Lauke> "what is the label" is a very subjective thing
<Patrick_H_Lauke> maybe need to prefix as "where it *clearly* is the label" ;)
giacomo-petri: e.g. birthday, date format, there are scenarios where we don't always want to include all of the text that is visually presented into the accessible name of the input
… the normative text is very clear, and sometimes the common sense suggests that maybe we shouldn't really include everything that is visually presented as part of the accessible name
alastairc: Do we have an issue for that, and would you want to write an exception?
<Patrick_H_Lauke> +1 we may just need to explain/acknowledge that "what is the label" may not be a 100% cut and dried thing
<Patrick_H_Lauke> that there is some measure of subjectivity
<mbgower> w3c/
[Mike shows example screenshot in issue RE fade near scroll boundary in #4622]
[discussion of whether it fails or not, since when you scroll the same text that failed before now passes]
alastairc: We've discussed things like that in the context of e.g. if you hover over a button and it loses contrast, it fails
… I'd potentially reach for the conforming alternative version, which is you scroll down and it becomes visible
<Zakim> mbgower, you wanted to say we can always try a sufficeint technique
Patrick_H_Lauke: Unless we wanted to add an explicit exception, "unless it's meant to be like that for everybody", but then that could be applied to a whole bunch of SCs
<Patrick_H_Lauke> mbgower should we add that to wcag 2.x backlog board?
mbgower: I think I remember hearing a suggestion from Gregg, if everyone is pretty clear that it seems OK, we can create a sufficient technique that demonstrates the usage. So it's not a normative change, and we can get away with it despite not following the normative language directly
… that was one of my takeaways from the previous session, don't try to box yourself into trying to tailor the normative language; solve what you can in informative
giacomo-petri: I think creating a sufficient technique to say the opposite of what we have in the normative text is not a good idea
… in the case of ruby, the normative text is clear, and is supporting the notion of adding ruby for programmatic relationships
<nigel> +1
<Zakim> alastairc, you wanted to outline the WCAG3 agenda item.
giacomo-petri: in this case, it'd be adding a technique to essentially form an exception around what we are normatively saying, so I'd be concerned
alastairc: Kind of relates to one of my bugbears: in conforming alternative version, it probably expanded from the original intent
… the original intent was you'd have a whole different page
… I think adjusting this could solve a lot of those problems, like the contrast one that Mike just raised
… without creating a massive loophole for everything
Reviewing WCAG 3 after the next publication (early new year?)
alastairc: One more thing before lunch break: we mentioned earlier there's potentially a WCAG 3 review
… this is just my thoughts on what would be useful; I'm very happy it's for the group to discuss and decide what's best
… we're going to have a new draft version soon coming out of editor's week, where everything is sort of conglomerated and we've tried to make it more refined and consistent
… we're looking for the mobile TF to do a review from their perspective, ditto ACT, and we're looking for this TF to do the same, to avoid stepping on the same rakes again
… this group tends to be really good at coming up with all sorts of things we wouldn't think of the first time around
… it might be good to plan this sort of activity for early 2026 e.g. January
… I suggest that if anyone can think of any more normative examples we want to tackle after lunch, that would be great, otherwise we can do essentially the standard friday session
Ken: Would the review be done on the PR preview, or the ED after it's merged, or?
alastairc: We're expecting to republish by EOY ahead of these reviews
kenneth: Would we be having people look at the working draft without the exploratory stuff?
alastairc: Yes, I don't think we have many exploratory requirements anymore
Backlog TF project board management
<kenneth> Board: https://
<mbgower> https://
<kenneth> https://
<Patrick_H_Lauke> btw before we get going, I had a small question/request for our process of triaging stuff in github...
<Patrick_H_Lauke> (once there's a natural break in mike's intro, nothing major)
<Patrick_H_Lauke> makoto feel free to go before me, mine is more of a final question separately
<kenneth> fwiw there's also https://
<kenneth> (to clarify the last thing Mike said, we tend to remove an issue from the project when we create a PR that addresses it, in which case the PR is now the representative entity within the project)
[mbgower gives intro similar to task force process wiki page]
Patrick_H_Lauke: RE response-only issues, sometimes there are very high-level Q&A type questions that sometimes come in; for those I've tended to turn them into discussions rather than keeping them around in issues.
… I know I've done it a little haphazardly; was wondering if we could maybe add something to our process to clarify when/how to handle that
mbgower: I've been mulling over what direction we should go if we get no further direction from WG; should we be keeping better track of the discussion area?
giacomo-petri: in the ACTCG, when you create an issue, you have options, using multiple templates. Maybe we can do something like that to filter, and we can associate labels to help triage issues
mbgower: I have trouble even telling how many discussions there are, the list view seems inscrutable
… (they don't show the total at the top as they do with issues/PRs)
Patrick_H_Lauke: It was probably intentional on my part to move them there, out of sight out of mind. Once a discussion happens, it might still happen that we decide that it's a good point that spawns an issue again
mbgower: Giacomo, if you have suggestions, we can bring them up in the TF admin
<Zakim> giacomo-petri, you wanted to propose a solution to at least partially solve Patrick's point
Makoto_U: I would like to thank each of the TF members for working hard on the issues, which impact everyone.
<Ben_Till1> Some docs on discussions... "About discussions": https://
<chrisp> +present
Makoto_U: As testers and practitioners, we encounter gray areas very often, and we check both open and closed issues all the time, and they're very helpful. Very appreciated. Doumo arigato gozaimasu :)
Nigel: Before lunch, Alastair shared a slide with a bunch of issues, and asked if anyone had any others, and we didn't actually cover any issues on that list. One of mine was the top one on that list, #4613. Is that something we might cover now?
<Ben_Till1> Link to 4613: w3c/
mbgower: I think we can be kind of fluid today since we have a lot of new people on the call today
<Patrick_H_Lauke> hah, suddenly matching up avatar/username with real-life person/face :)
nigel: #4613 is about people interpreting Audio description SC to mean that in order to meet the criteria, you need to provide an additional audio description resource, an alternative soundtrack. It looks like you have to do an additional thing.
<Patrick_H_Lauke> i have a feeling there was something already worked on by mbgower that covered this? (as part of another 1.2.3/1.2.5 issue)?
nigel: the situation that the normative text doesn't really make clear is that, if the audio of the program content already describes what's in the video image, then you don't need to do that. The text in the Understanding section is perfectly correct, but the normative text doesn't read the right way / can be misinterpreted
mbgower: to give an update, there's a number of AD PRs in progress, with a number of comments as well, and we ran into an impasse where there is a conflict in interpretation of the language.
… we sent a survey which was an extremely focused question (about lack of gaps). Not exactly in the same area as this issue
<Patrick_H_Lauke> fwiw in the specific case of 4613, i think updating the definition for audio description, adding a note to it, would be my preferred way forward
mbgower: the normative text is pretty succinct; if you expand the definition of audio description, it includes important visual details that are not conveyed in the soundtrack alone
<Patrick_H_Lauke> it would still be a normative change, but the least disruptive one
nigel: my concern is that the really important part is in informative text, and needs to be in normative
… you should be able to delete the notes and still come out with a sensible understanding, but I don't think that's currently true
mbgower: There are 2 general approaches being debated at the moment. One is that we can get clarity in notes without altering meaning; at what point do we need to do something in normative text?
… haven't heard that the note is contradicting the normative text
nigel: except me :)
kevin: For clarification: you said the definition of audio description doesn't provide for that, but it does - "that cannot be understood from the main soundtrack alone"
<Zakim> kevin, you wanted to react to nigel
nigel: I understand that reading, but I don't entirely agree with it. The immediate reading suggests that you need an additional thing, though it ultimately cancels out
… people are seeing it as, to tick this box, you must have an additional thing
kevin: I would argue that's not what it says and they're wrong :)
… if we try to change it to address them being wrong, then we're probably going to tie ourselves in knots and make something more complicated. I think as it's defined, it's pretty clear.
… it doesn't actually say you need to add an audio description. It says if you need an audio description, you have to add one.
kevin: My reading of the definition is quite clear, so I'm wondering where people are getting lost
<mbgower> narration added to the soundtrack to describe important visual details that cannot be understood from the main soundtrack alone is provided for all prerecorded video content in synchronized media.
mbgower: It certainly doesn't read elegantly when it's dumped in.
… ideally, the definition should work within the flow of the sentence where the defined term is used.
nigel: If you're in a testing environment, and you found a video that doesn't look like it has an extra audio track that isn't the main soundtrack, some people would go "oh, it's missing an audio description". You might say they're wrong, but that's absolutely where some people go with that.
<Ben_Till1> The text with all definitions in parentheses after the words that they define: Audio description (narration added to the soundtrack to describe important visual details that cannot be understood from the main soundtrack alone) is provided for all prerecorded (information that is not live) video (the technology of moving or sequenced pictures or images) content in synchronized media (audio or video
<Ben_Till1> synchronized with another format for presenting information and/or with time-based interactive components, unless the media is a media alternative for text that is clearly labeled as such).
Patrick_H_Lauke: the conditional is in the definition rather than directly in the SC normative text, but it's still normative
mbgower: There's something really related to this that really bothers me, and there are a lot of circular problems with the time-based media ones, where this is one of them. It talks about the main soundtrack and then the soundtrack
… I as the consumer of the video have no idea what the main soundtrack has been at any period of time. Someone could have corrected information directly within the main soundtrack and resolved it all.
… the standard seems to call for some additive thing that's not present immediately, and does a disservice to itself in how it's described. We've been trying to tackle this a couple of ways
<Patrick_H_Lauke> if we wanted to change the definition, it could be something more like: "narration to describe important visual details; if this is not present in the main soundtrack already, it can be added to a separate soundtrack"
mbgower: either adding additional information into the normative text to cover some of these things, or (in WCAG 3) breaking this up more.
… we're trying to gather all information and see what we can get away with that is a happy direction for everyone, that we can live with, if we're allowed to change the normative text
… the bigger problem we have right now is the issue related to interpretation RE lack of pauses
Patrick_H_Lauke: I dropped in a comment on IRC. If we wanted to go through the pain of changing the definition, we could try turning the conditional around, but I can't guarantee that people will read the updated definition any better than the original (if at all)
… but maybe we could make it clear the conditional is not the end
shadi: I wanted to mention there's another WAI resource that talks specifically about media
<Patrick_H_Lauke> https://
shadi: it's even more informative, since it's not even a note. It's a very helpful resource. I understand what you're saying, Nigel, about the normative text and how it can be misread, and how the note also is technically informative
<Zakim> mbgower, you wanted to say that there is a fundamental challenge with "main soundtrack"
shadi: but if you have all of this, and you have all the support information, I think it's good enough for now. There are bigger issues that are like, do we go down the stream of fixing it now and creating better requirements in WCAG 3, there is that trade-off
<Zakim> nigel, you wanted to say that ideally we would change the criterion to reflect the desired outcome, and adding audio description is one technique
shadi: for this particular issue, if you want to be in good faith, and if you look at the guidance the organization is providing that created those guidelines, it's really pretty clear
<Patrick_H_Lauke> otherwise, if we wanted to fix this at SC level, we'd need to prefix the normative SC wording with "Where necessary/not already conveyed in the primary soundtrack, audio description is provided..."
Nigel: I understand the intent, and the informative text, and I don't disagree with any of it, I just want it to be in the normative text
shadi: These things happen, I was in the EN 301 549 when these things happened
… it's because people insist on looking at only these snippets without the larger context
nigel: The wider point worth bearing in mind, is the outcome that everyone wants is that if you can't see what's in the video image, you can still understand what's going on
… the criterion should be the outcome; audio description is a technique
… providing timed text alternative could be another technique
… there are at least 3 available techniques for meeting that outcome, but we don't describe the outcome, we're describing the technique. Maybe that's a WCAG 3 thing.
mbgower: If we get support to be able to make some adjustments to the normative language, what you just described is what I'm hoping can get captured in there.
… there's also some interesting things in 1.2.3 (AD or media alternative), and if you look at it, it's saying the A is really the AA or the AAA. There's not really a baseline criterion
… you either have audio descriptions that capture everything, or have a full-blown transcript
… even the single-A is quite prescriptive
<Patrick_H_Lauke> what "synchronised" actually means is another can of worms that we tried to tackle...and failed
mbgower: there are quite a few scenarios that I think you can provide equivalent that don't line up with any existing SCs
… hoping to come up with something to have a constructive conversation and some buy-in on
<Patrick_H_Lauke> +1 to nigel's point about "the SCs for AD aren't talking about a user need, but ONE way to achieve an outcome only"
<mbgower> +1 from me as well
<Patrick_H_Lauke> wai-ig mailing list often has low quality answers, i'm sorry to say...
<Patrick_H_Lauke> there's a few people that love to just sidetrack any question into their own hobby-horse
<Patrick_H_Lauke> (standard "just don't do it that way" rather than providing answers)
<Zakim> nigel, you wanted to wonder if we can conclude this now or what the path is to doing so
kenneth: Would wai-ig mailing list serve as a reasonable outlet for discussions? (Maybe not)
… and RE issue templates, there's sort of cost/benefit involved since it adds friction every time an issue is being created, need to make sure it's warranted and the options are clear if we do it
<Patrick_H_Lauke> I'm happy to make a speculative PR that changes the definition
<Patrick_H_Lauke> in answer to Nigel's question
nigel: [further question RE audio description]
mbgower: We're hoping to get some questions into a survey that WebAIM is doing, and hoping we can do some work on 1.2.3 and 1.2.5 to be more clear and logical on what they're asking for and how they combine together
… we're not going to solve that right now, but we do have work queued up to be doing on that in the TF
… depending on what we receive from the WG, we may have a good chance of doing this in 2.whatever, otherwise will have to be done in WCAG 3 going forward if we can't resolve it for 2
<Patrick_H_Lauke> (also to manage expectations, nigel ... some of the things we work on in wcag 2.x backlog TF can take...quite a long time to come to fruition. see some of the PRs of mine from 3+ years ago)
shadi: Encouragement for Nigel also, is there anything you feel in the understanding documents that we can make even more abundantly clear?
nigel: The informative stuff I think is great
giacomo-petri: RE ken's point in adding issue templates, I agree we don't want to do more harm than good. Want the bare minimum - raise an issue or raise a question, so that we can decide whether questions can be responded to within the issue or warrant moving. Make it easier for us to decide
<kevin> +1
<Zakim> kevin, you wanted to respond to mailing list
<Patrick_H_Lauke> so a very lightweight issues.md form that includes just options of "i'm raising an issue" vs "i'm asking a question"
kevin: I think there was talk about wai-ig mailing list, Patrick I acknowledge what you said, but I also think there's some value to leaning in to using the IG mailing list for what you're doing. Maybe going back to Murata-san's topic, using it as a way to communicate changes
… communicate more frequently and let them know what they should be paying attention to
… finding ways to better communicate what we're doing. Not a big thing, light is fine
Patrick_H_Lauke: Right, I just wouldn't want to be offloading our triage to them
<Patrick_H_Lauke> +1 to leveraging wai-ig more. my concern was more about not just offloading any Q&A to wai-ig, as the quality of answers on that list is not always very balanced/representative/authoritative
mbgower: Would it make sense to do a round table to find out why people are here, if they have any questions or input for the TF?
Jaunita_Flessas: I'd like to do more, but there's only so many meetings in the middle of the night I can attend :)
<Patrick_H_Lauke> perhaps should we have a flip-flopping meeting time?
mbgower: Is there some way we can improve the async work?
Jaunita_Flessas: Is there a way we could summarize the IRC logs? Maybe identify ticktes?
<kenneth> https://
<Patrick_H_Lauke> actual resolutions are in the issues themselves, generally
Jaunita_Flessas: oh this is like how the ARIA WG works
shadi: I've been watching this from the sidelines; here just to get an update, a sense of what's going on, more in-depth
… better assessment of another WCAG 2.x or not
… would like to have, at least in my head, a listing of the issues that require a normative update with pros/cons
… e.g. this particular issue might involve a normative update, but IMO it's not worth the effort
ChrisPryor: I'm managing a team that audits for WCAG 2, wanted to see what goes on. One thing on my mind was notification when there are changes to non-normative text; it would be really handy if notifications were sent in the moment that happens
kevin: Ken and the TF have done a lot around e.g. the change log management. It might be good to further or more broadly communicate proposed/enacted changes
LenB: I didn't have anything specific, just curious how things work
Ben_Till1: I tend to use my headspace for the Tuesday call, don't make it to Friday backlog TF call often
… worried that if I try to start something, life things will get in the way, but would love to tackle small things
Patrick_H_Lauke: you can feel free to comment on issues, doesn't mean you'll be roped in / committed to anything long-term
<Patrick_H_Lauke> +1 wcag issues were a huge technical debt
mbgower: When the TF started, there were almost 800 issues in the backlog, and I don't think it gave a good signal to anyone that the standard was being maintained. We're now down to ~500, and of course more get opened, so we're now down to more closed than opened
<Patrick_H_Lauke> i am beyond thrilled at the work we've been doing. both simple/"trivial" things that make informative documents clearer/better understandable, and also surfacing long-standing pain-points
mbgower: want to make it easier for people to find low-hanging fruit vs. meatier stuff