Meeting minutes
<Demelza> +present
[Introductions]
Agenda Review & Announcements
janina: Transition to TPAC follow-up shortly. TPAC 2025 announced. In Japan next year in November.
APA WG Recharter 2025
<Roy_Ruoxi> - github: https://
<Roy_Ruoxi> - draft: https://
Roy_Ruoxi: General announcement regarding follow-up APA new charter
… see previous links. New drafts
Roy_Ruoxi: if any issues, please submit in GitHub APA repository
<Fazio> Maturity Model TPAC Follow Up Note: WCAG 3 is using a lot of references to Maturity that have nothing to do with Maturity Model - I see issues with this
janina: Hope to proceed with new charter in place when current one expires next year
<Fazio> Maturity Model TPAC Follow Up Note: Next charter I would like to explore possible normative specifications for the Maturity Model. This could lead to incorporation with WCAG 3
janina: Need to project what and when we plan to deliver before July 2027. Good for task forces to look at their own deliverables before bringing them up in this group
Fazio: Will just reiterate my concerns about WCAG 3 referencing maturity which does not mean maturity model
janina: Acknowledged and will work on that in future.
janina: All TFs have very solid actionable next steps, which is promising. The minutes reflect that
<matatk> TPAC 2024 wiki page: https://
Task Force & Deliverables Updates
janina: David Fazio is almost done with Maturity Model and hopes to move into 1.0 note by end of year
janina: Notes from RQTF that won't be ready until November.
New Charters Review
Publishing Maintenance Working Group Recharter
<Roy_Ruoxi> - charter: https://
<Roy_Ruoxi> - issue: w3c/
Roy_Ruoxi: 1 new charter this week. See previous links
Roy_Ruoxi: Noticed there are a lot of deliverables that mention European Accessibility Act and specifically EPUB
Roy_Ruoxi: They list us as liaison working group to collaborate on accessibility issues. They noticed we had a presentation on HTML work.
Roy_Ruoxi: Charter looks good to me from a11y perspective
<matatk> +1 LGTM
janina: I spoke yesterday with Charles LaPerriere about structuring a11y provisions
<janina> ~q?
gpellegrino: Still discussion around it, not quite finalized. Might be worth to wait a week or two to have more stable version before deciding
janina: Want to extend thanks to Gregorio and Gautier regarding fixed layout and the work that was done during TPAC. Our oversight responsibility is being conducted nicely and big thanks to you.
Issue Review Requests
EPUB 3.3
<Roy_Ruoxi> - issue: w3c/
<Roy_Ruoxi> - spec: https://
<Roy_Ruoxi> https://
Roy_Ruoxi: Also from the same WG. EPUB 3.3 wants to go to CR due to changes in the document. There are four changes in their document. They asked for review from a11y perspective. Last time the document was reviewed by Janina and Fredrik.
<matatk> This looks like the change log: https://
gpellegrino: Only changes are minor changes, errata, etc.
<Roy_Ruoxi> The candidate changes, with a reference to the relevant issue discussions, are:
<Roy_Ruoxi> https://
<Roy_Ruoxi> https://
<Roy_Ruoxi> https://
<Roy_Ruoxi> https://
PaulG: I know we've discussed fixed layout and that is addressed in this document. Is that something that needs future revision or not likely to be reviewed?
janina: During TPAC, we agreed to be clearer of the limits of what is achievable vs not with fixed layout. A more informative title would be helpful.
PaulG: Just to be clear, EPUB community is still not amenable to addressing a programmatic way to address reading order in fixed layouts
gpellegrino: I think that the new charter will be the continuation of that topic. Since these are minor tweaks to an already published document we can't introduce anything major at this point. Hoping this will be part of the new charter.
janina: Suggesting we sign off on this
matatk: Couple of things. Firstly, I'm confused why we're being asked to review if we're expecting further changes. Are we definitely expecting these? It seems that it's been labelled in such a way that it's ready for review.
gpellegrino: Can't say for sure as I'm not the chair, but there is some discussion on GitHub
gautierchomel: Labelled as "advanced notice sent" which indicates it's still a draft and can be quickly assessed
Roy_Ruoxi: Normally when a charter comes to us it means it's ready for horizontal review
matatk: Good idea to verify the process and ensure this charter is following correct protocol.
matatk: Other concern: There are 4 issues listed here for the EPUB 3.3 spec. Shouldn't we look over them or are we saying that they're been looked at by Gautier and Gregorio and they very minor?
gpellegrino: I think it's best for someone to review. I was just mentioning that they are small changes and shouldn't take much time.
mike_beganyi: Will take on action to review four issues listed above
CSS Update (Paul)
PaulG: I reviewed the agenda from TPAC and will do my best to provide a more thorough update next week
Actions check-in
matatk: First action is that the Accessibility Conformance Testing Rules format 1.1. The subgroup responsible will be meeting soon
matatk: Other one we were looking at is Vibration API.
Vibration API
<matatk> Previous APA comment: https://
<matatk> Tracking issue: w3c/
matatk: Decided last week that we would follow the new process inspired by i18n. Bring it up on the call, close it if we can, if not, make an issue that could be seen by responsible group
matatk: The thing we are concerned about is ensuring that vibration can be disabled i.e. Vibration MUST be able to be disabled
matatk: Initially in 2016 indicated that a user SHOULD be able to disable it but now MUST is recommended
<Fazio> Is should ever a relevant request? It has no weight
<SteveF> +1 tp PaulG
PaulG: I was the one fighting for MUST last time we talked about it. However, the ability to customize vibration should be within the user's control. If the device can provide variation in that haptic feedback, then it can be a softer must. If the device does not offer customization on haptics, then a stronger MUST must be used
<Fazio> I feel like we should never make requests through terms like should, because they're non-committal
matatk: My understanding of your concern Paul is for the user to be able to determine which app the haptics is coming from. My personal concern is that we're getting some views that some users with motor control issues or sensitivities, they may just not be able to cope with that type of haptic feedback.
matatk: The action for me from last week still stands with some information as to why we've changed our view
PaulG: Can we add a SHOULD? Ability to map haptic patterns SHOULD be implemented?
matatk: I think it comes under Devices and Sensors. It could be brought to their attention as a separate issue
matatk: Sounds like two issues for me to propose.
PaulG: You can tag me on it Matthew.
matatk: Want to acknowledge that David Fazio spoke to SHOULD and it's indefinite implication.
<SteveF> https://
matatk: We have specific definitions and it's fair to say that we can move to a change in language given the nature of device changes in recent years
janina: I think we can tell them that we are inclined to ask for MUST whereas 8 years ago we were happy with SHOULD and ask if that creates a problem for them.