wilco: We have had an approval from AG to update update definition of accessibility requirement
<Wilco> https://github.com/w3c/wcag-act/pull/450
wilco: Shadi what is the next step? We have a draft, the pull request is still open. I think we can merge now to have an updated editors draft.
shadi: We can update the editor draft? We should note this in the errata. Getting a TR is pretty difficult, so unless it is a big issue we may want to wait.
... We need to decide if we can live with it being in the errata and linked to the editors. When we get to the next version of the spec we could add these. Or do we think we have reached that threshold now, that we need to look at doing this.
<shadi> https://w3c.github.io/w3process/#revising-rec
shadi: I will have to go look up more to see what is required.
... Do we consider these substantive or editorial? We are changing a definition.
wilco: It doesn't change the requirements, but it changes the meaning of the definition to be more inline with how it was inteded to be use.
shadi: If someone were to implement a rule using the current version vs future version, would they be compatible?
wilco: Yes that would be the same.
... The problem was that the definition was inconsistent with how it was used within the document. If you follow the requirements within the document then nothing changes.
... If you don't follow the requirements and instead follow the definition then you would not list best practices
... No I don't think it is a substantive change since nothing changes if you are following the requirements
shadi: This is a clarification of the definition. Can I interpret it in a certain way that would be incompatible with the future spec.
... My guess is that if we do ask to update the definition, which is part of the normative requirement, then it will be looked at very carefully.
kathy: When I look at the changes, the main change is that the accessibility requirement is allowed to be advisory, which it didn't before. I think it allows more flexibility
shadi: That may support that you can't currently write a rule that would later become inoperable
daniel: It is broadening the definition, so it shouldn't affect what is currently written, it is accomodating future best practice rules
<Wilco> An ACT Rule must indicate whether or not the accessibility requirement it maps to is required for conformance in its accessibility requirements document.
wilco: Don't agree with broadening, it is possible for an accessibility requirement not to be required for performance. ^^
<Wilco> 4.4.2
wilco: if an accessibility requirement was always needed for conformance then this statement would not make sense.
shadi: How does changing the definition change other sections
<shadi> https://w3c.github.io/w3process/#revised-rec-editorial
shadi: It looks like we are leaning towards editorial, but we should take a bit more time to look at it and justifying it.
... The link above would allow us to bypass a lot of the process.
<shadi> https://w3c.github.io/w3process/#editorial-change
wilco: I don't know how we can prove it. We can go through what we have and ensure those are not impacted.
<shadi> https://w3c.github.io/w3process/#editorial-change
**I am starting to break up**
can someone else grab scribe, I am getting kicked out
<dmontalvo> scribe+
<dmontalvo> Kathy: IF someone wants to create a best practice ACT rules that there is no flashes, since this is a best practice, would the change on the accessibility requirements definition allow me to say this is advisory under 2.3.1?
<dmontalvo> Wilco: No, it still needs a fail-to-fail relationship in the document.
<dmontalvo> ... If WCAG had an additional recommendation about flashes, explicitly saying "Try to avoid flashes" but that what wasn't required for conformance, that could be an example
<dmontalvo> ... WCAG success criteria are always required for conformance. Maybe some of the techniques could be argued to be advisory for WCAG
<dmontalvo> Wilco: Should we publish this update?
<dmontalvo> MaryJom: We could treat this as an errata, and avoid the whole process.
<dmontalvo> Wilco: We could do that. I see your piont about time.
<dmontalvo> Daniel: I see the time constrains, I would leave it as an errata.
<dmontalvo> Shadi: The errata is a llink that appears below the editor section, when you click it you are taken to a place where these things are shown.
<dmontalvo> ... I need to check with others, it is a bit of a balance between value and effort.
<dmontalvo> ... In addition, we could merge the change into the editor's draft.
<dmontalvo> Wilco: Why can't we make substantial changes in the errata?
<dmontalvo> Shadi: The errata does not override the document, but at leasat we acknowledge that the problem exists
<dmontalvo> ... The document never changes. The errata is only pointed to from the link mentioned above.
<dmontalvo> Wilco: Lets vote, +1 to updating or -1 to not updating.
<kathyeng> -1, errata is fine
<maryjom> -1
<Wilco> +1
<shadi> +0
<dmontalvo> +0
<dmontalvo> MaryJom: Maybe in the future we end up with other things to change, we could change them together.
<dmontalvo> Shadi: We still don't have such a large community that is asking for clarification at the moment.
<dmontalvo> Wilco: I will merge this pull request then, and we may need to update the document with the errata.
<Wilco> https://github.com/w3c/wcag-act/pull/450
<dmontalvo> Wilco: We said a couple of weeks ago that we would mae suggestions for changing the notes, see my comment from three days ago.
<maryjom> https://github.com/w3c/wcag-act/issues/449#issuecomment-636827723
<Wilco> This rule checks that a non-embedded HTML page has a title. HTML pages embedded into other documents, such as through iframe or object elements are not applicable because they are not web pages according to the definition in WCAG.
<Wilco> https://github.com/w3c/wcag-act/issues/429#issuecomment-634137703
<maryjom> https://act-rules.github.io/rules/cae760
<Wilco> https://act-rules.github.io/rules/7d6734#applicability
<dmontalvo> Wilco: I am not sure if notes are even necessary in `svg` element with explicit role has non-empty accessible name
<kathyeng> https://github.com/w3c/wcag-act/issues/429
<dmontalvo> Kathy: I put my suggestions in another issue (link above)
<Wilco> https://act-rules.github.io/glossary/#web-page-html
<dmontalvo> Wilco: I think I prefer not to put it in the applicability.
<dmontalvo> Kathy: Option one is to add it to the existing second bullet
<dmontalvo> ... I have it currently in parenthesis but and has the same meaning.
<dmontalvo> Wilco: "and" could be interpreted as a separate requirement instead of the opposite.