Meeting minutes
<janina> ate: 11 Sep 2024
janina: Proposing we meet next week 18 Sept, then take off 25 Sept and week following
… due to TPAC
Lionel_Wolberger: 2 Oct is Rosh Hashanna
Lionel_Wolberger: The group agrees.
Welcome & Introductions (As needed)
Whither Capabilities?
janina: Frames the issue of how to get the most value out of this document as it stands now.
… propose re-titling the document
… Jason has been proposing that for a long time
… after re-titling, we re-write the abstract
… this document examines the opportunities to refine accessibility after the source is committed
… this is the minimum
Mike: I suggest we put a time limit or deadline as well
<Lionel_Wolberger> +1
Lionel: Proposing titles
… ... Post-Source Accessibility Capabilities
Mike: Who is the audience?
… let's brainstorm here, as I'd like time to consider
janina: Let's get a provisional title
jason: Post-source accesibility techniques and capabilities
Mike: Post-Source Accessibility
Mike: What is 'source'?
Lionel: The group continued to brainstorm. Post Source Code Accessibility
… post production accessibility
janina: 9 am Thursday 26 September we are getting an overview of what is coming in WCAG 3
Shari: Invite me too
Lionel_Wolberger: Accessibility capabilities post-source code or content
Jason: AS long it includes browsers
… something is live. How to we further improve something once it is live
… could be browser manufacturers, AT, etc
janina: there could be a sub-title
Lionel_Wolberger: "Improving" in the subtitle
Lionel_Wolberger: Accessibility capabilities, post-source code or content
Mike: +1
<janina> +1
Jason: +1
Shari: +1
TPAC
Next edits
Jason: We need a new abstract
Jason: Let's re-examine the recurring subheadings (the current definition list)
… Source, Trade-offs, Benefit, Automatability
Lionel_Wolberger: Perhaps we can combine the first three into one subheading, Considerations
janina: There are recurring themes
… such as a portable configuration that a user takes to every website
… this requires being done in post-source
jason: Most things are likely best, when done at source
… but there are often compelling commercial reasons to do it post-source
… and often there is minimal to no downside
… The document is a guide to how you can do things post-source
… and should show the potential pitfalls
… as for example, when post-source code hinges on source code (where the source developer does not know there are downstream code )
… and if the source developer makes a change, it will essentially turn off the post-source code
… so there is a level of collaboration with the people who manage the source code that is required
… for much of these post-source fixes to be robust
janina: Clarifying that the audience is W3C brings new nuances to the fore
janina: Can we go with Accessibility capabilities, post-source code and content
Shari: +1
Jason: +1
Lionel_Wolberger: +1