11 September 2023


Im Song, Janina, jasonjgw, julierawe_, Lionel, Lisa, lisa__, matatk, Mike, mitch11, Mitchell, Roy, theAli
Lionel_Wolberger, matatk, Roy

Meeting minutes

COGA and I18N

Lisa: Working on an update to Content Usable. Want to address internationalization.

Lisa: *presents slides: https://docs.google.com/presentation/d/1iGYvCk2BPMplbYT3w3ROAyZXCUnN5g8nsiMcphRrAAI

Lisa: Goals are to update Content Usable and also WCAG 3. Content Usable needs to be more aware of Internationalization, as does WCAG 3.

<mitch11> As an observer should I present plus?

Lisa: CU is perhaps broader than WCAG, so may have fewer covered languages.

janina: Might be an idea to ask how we can make clear statements more comprehensively across multiple languages; asking i18n for help as we go through.
… Gives example of double negatives in Russian, for example.
… Goal is to talk about what is being proposed, and start building a relationship with them.

matatk: What stage is the WCAG work at?

Lisa: Subgroup of COGA, working with WCAG group, early days, but with methods and conditional statements proposed.
… Good test case for the more flexiable structure of WCAG 3.
… Quite well devleoped; have been working on it since WCAG 2.

<lisa__> https://www.w3.org/TR/coga-usable/#objective-3-use-clear-and-understandable-content-0

<lisa__> content useable link

Lisa: ^ link to design guidance in Content Usable.

Lisa: There are common words in different topical areas, so some sites about specific things (e.g. music) may be using those specific words, and that can be user friendly. What those common words are depends on the context.
… *Gives example of "the tube" being a common term in London, but not elsewhere.

matatk: What are the "conditional tests" exactly; the things in the CU design guidance?

Lisa: The tests for whether those criteria (e.g. use short sentences) are met depends on the language; there are different ways to test for them in different languages.

Lisa: We previously didn't notice that an issue that I18N had raised, and we thought addressed, had been re-opened; we want to ensure that doesn't happen again, and to work with I18N more closely.

Meeting prep

ARIA (Notifications)


Proposal doc: https://docs.google.com/document/d/17kKNoCIoMSFMFicz0wSQR-PHWHfHGYfz1WdtHMYyrhE/edit#heading=h.r83mzc4f0o33

matatk: not general case for them
… I agree with that
… but I do have something questions, this idea is develop to ask screen reader to say something

WebAIM stats on disability type: https://webaim.org/projects/screenreadersurvey9/#disabilitytypes

matatk: only 3% use screen reader as cognitive purpose
… wonder how ARIA through about this use case may cause confusion for people to hear something they can't see on screen.
… when we talk with them about notification what's the scope?

janina: w3c/input-events#74

matatk: help them to explore, one is how screen reader say out, other is browser support
… how to apply this to everyone


matatk: this is a general case for screen readers
… the scope of ARIA looks powerful, but not something in general
… this issue looks more general
… I think the question is if they want to treat them as the same way
… good have those context
… looks those are different issues to me
… I don't have concern on the API
… but we need figure out what it will do, or what need us to support
… some case may useful, but sometimes is not
… I purpose to raise our concern as an issue

mitch11: negative example and positive example for both side

mitch11: Attempts at orientation to the content on the page, e.g. when something gets focused. Arguably too much info.
… Your example of a table row having been deleted (assuming no other notification, just the fact that it disappeared). Arguably a status message in WCAG terms. Good example.

Lionel: We don't necessarily want to give the developer access to the SR user's experience (most devs may not understand the experience).

matatk: it does resolve some issues, but sometimes user may not want to get information from that, so there need a solution on that
… ARIA did a good proposal, and allow us to visit this

[matatk is showing a tool to check the actions]


janina: Proposal for expert handlers (e.g. MusicXML) - issue to be proposed for EPUB meeting tomorrow.

Jason: Interesting idea; there are problems to solve regarding context, and loss of context when handing over to the specialist renderer.

janina: There are some existing approaches to this that we could look at; EPUB's OPF packaging works well, for example.

Jason: when looking e.g. at MathML, the best intrfaces to this don't take you out of the document; they provide the accessibility info through the browser. There is a tool such as Speech Rule Engine, or MathCat.

janina: Are the browsers going to support this for all subject areas?

Jason: the processing of the accessibility info is done ezxternally.
… There is a process by which the MathML gets transported and processed. Speech Rule Engine is in JS, so has DOM access. MathCat has some process to access the MathML, but not entirely sure what it is.

janina: Does it support on-screen viewing?

Jason: Browsers implement this themselves (or could use MathJax).

Jason: Work is being done on Chemistry too (both Speech Rule Engine and MathCat). Will send more info about these. There is a tool that processes chemical diagrams.
… it uses ARIA and SVG.
… We've not looked into music a great deal; can take an action to bring together some of the refs on this.

Matter about determining if an image is described in surrounding text or not: https://github.com/w3c/epub-specs/wiki/Image-Missing-When-Described-in-Context

Jason: this doesn't need to be exported to the user; it can be included in a publisher's workflow.
… In my experience, when images are discussed in the surrounding text, the text depends on the user's ability to see the image. It doesn't provide the same info that a properly-written alt attribute would provide. Providing a way to flag images in this way would
… give authors/publishers a way to opt out of providing good alt text, because they might fail to do so in the surrounding text for subtle reasons.
… I.e. the surrounding text would probably give you the author's interpretation of the image, rather than its actual content.

janina: What is an appropriate description depends on what context you're looking at it in.
… E.g. studying costume design? You might be looking for some very different info than someone looking at it from a theatre set design point of view.

Lionel_Wolberger: Issue raised very thoughtfully.
… By including the 4 use cases, they've shown there's more than the end user involved here.
… alt="" is ambiguous.

Lionel_Wolberger: AI is getting good at summarizing text; telling it that the image is described by the surounding text could be very useful. E.g. for cognitive access reasons. Multi-modal access is important.

<Fredrik> BRB.

matatk: The issue of context in alt text (costume designer vs set designer) - alt text intended to be more "factual" so could be interpreted by anyone? Interesting isssue; opens up quesitons related to other discussions such as the notifications subject earlier.
… However, concentrating on mechanincs of the question: is not being able to skip to the image a big downside? I agree with Jason that there's a risk (unknown, but present) that providing an "escape hatch" to authors, no matter how well-meaning, could lead to a loss in quality of alt text.

jasonjgw: The wider issue is interesting. Often I find the surrounding text is not intended to substitute for viewing the image. Does "surrounding text" mean adjacent? Or several sentences away?

jasonjgw: Concern about encouraging the practice of using surounding text as the label for the image. The larger issue janina was pointing to is interesting.
… Some image-processing image models are very sophisticated; can answer questions about the content of the image, including domain-specific capabilities. This goes beyond HTML. But these models have a capacity to generate false information.
… Coming back to Lionel_Wolberger's point, what assistance could we give them to improve their accuracy?

matatk: Both of us agree, that this is 'risky' in that people might say, image is described by surrounding text, when it is not
… perhaps George finds that scenario more common than not
… if we focused on that would we feel differently?

janina: We're discussing all sorts of best practices, but you want to know where the image is, and you might want to put focus on it, because you might want to share it with someone, and so it shouldn't be hidden.

jasonjgw: Agree with Janina. The proper approach would be to have a short alt text phrase that's specific to the image (and refers to surrounding text if need be to describe it).

Lionel_Wolberger: Thinking about how to wrangle the issue.
… alt="" - classic engineering problem
… of how to represent "null"
… There should be a way to mark this up.
… I think we should try not to make the AI usage the issue here, but we should have those exciting discussions.
… There is greater capability, but it is far from perfect.

Agree that if we give devs the option to say "described in context" we will see a lot of these.

Lionel_Wolberger: the desire to share/manipulate the image, even if we don't see them is fair, and could apply to decorative images.

Lionel_Wolberger: (1) lack of null; (2) generative AI; (3) risks of "described in context"; and (4) AT shortcuts to images even when they are decorative (or have null alt); _and_ (5) who here has struggled with "it's decorative, but it's expressiong the emotion we want conveyed with this brand (e.g. photo of happy people)"

matatk: We have discussed that 'decorative' is not appropriate when the image is expressing an emotion or quality that is significant to the page

jasonjgw: There is a contraversially decorative-or-not image on the front of Bach's Fuges.

+1 to jasonjgw

matatk: If we wanted to make it so, e.g. 'g' in SRs could skip between images that were decorative, would we want that? Would we find we wanted to distinguish between _reallY_ decorative ones, and ones descried in text? (if we could provide such a feature, which I don't think is technically possible)

jasonjgw: Providing an informative image that doesn't have _some_ alt is against current guidelines, so we would either have to go to AG/ARIA/both to change things.

janina: APA's interest would be about "can we get at the information we need", we should let EPUB discuss the best practices in here.

matatk: Was thinking about the <picture> element, relating to this and the discussion before about announcments. Maybe looking at it too deeply, and the solution is to provide a different web page for different interests. We should try to stick to the mechanical.

Interlinear text

janina: Does anyone have any visual examples of interlinear text?
… We should take it up with i18n.

Looking at https://biblehub.com/interlinear/matthew/1-1.htm as an example

Lionel_Wolberger: *inspects code and notes that it's a table*

Lionel_Wolberger: A second one provides a whole paragraph, and then a separate paragraph below that is the translation.
… Another site offers a PDF that's laid out like the first site.

links to PDF, https://www.scripture4all.org/OnlineInterlinear/Greek_Index.htm

Fredrik: What do we want out of interlinerization? Do we want built-in concordance/linkage?

janina: The main idea is to pick up on the structure, so the reader can begin to pick up on the new language. The aim is for better language-learing tools.

Fredrik: Could this be applied to easy reading versions?

<julierawe_> Thanks, back in a bit

Reviewing CG updates

Accessibility for Children

janina: They've been working on a lot of analysis as to how educational materials might be categorized and re-rendered for improved accessibility for learners.


a11y for children, https://docs.google.com/document/d/18CDOklgwNYK2gILIz_IADeU_TiyQW6kuJWfP3Nhfk1c/edit#heading=h.jk39el5pm0qh

janina: Action on the Adapt TF to continue going through the feedback, and tying it into the TF's goals.

janina: We want, and need, to facilitate complexity management, for a range of people.

janina: This relates to CTAUR too.

https://www.w3.org/TR/ctaur/ - Collaboration Tools Accessibility User Requirements

janina: Import of collaborative tool accessibility got bigger, because some OSes/OEs are dropping apps for web-based solutions.




Lionel_Wolberger: The CG started one year ago, at TPAC, due to discussion about certain technologis that operate in end-user browsers. E.g. (refering to previous session topic) adding alt text to images.
… It's a very passionate discussion. We found that there were not clear touch points for the discussion.
… We want to make an inventory of capabilities that technology that works at the edge has.
… Will be presenting a breakout on this. We have a list of 40 capabilities.
… We know that, for example, APA and others are keen to "kill CAPTCHA" - but this depends on identifying who is at the edge.
… Another applicatino is having a privacy-preserving profile/credential that allows people to receive adaptations e.g. for accessibility reasons.
… We will be presenting it as a breakout and are keen for APA to take up some of this work.

jasonjgw: There may be guidelines as to where certain types of problem should/shouldn't be solved. However, nothing should be put off limits in general. Looking at specific accessibility issues is a case-by-case situation, in which we ask: which technologies are best placed to solve these problems?

janina: This is the sort of aapproach we took with the document we're working on.
… We look at problems, advantages/disadvantags of doing them both at source, and at the edge.

jasonjgw: Where this night intersect with APA's work is to look at specs being reviewed and looking at which aspects of a problem that's identified would be best addressed with edge technology, or not.
… Also there is value to having a broader understanding of this, and to create general guidelines on it, e.g. from the W3C TAG.

janina: A good example is having privacy-preserving config for accessibility (and having them applied across sites).
… (as we discussed in Vancouver at TPAC 2022)

Lionel_Wolberger: Another argument for discussing it is that it is a technological approach that's being used, and it makes sense for APA to be involved in discussing it. Other standards grew in W3C space; this one grew from outside, but should be covered by WAI's oversight.

janina: One that's not in the document, but has come up in APA discussions was around advertisement - we need to find ways to work with adverts and accessibiltiy, as it is a fundamental part of the modern web; our members discussed ways that we could incentivize more accessible ads.

jasonjgw: One development in security at the moment: starting to require tracking of components that are used in the construction of an appliation, and where they came from, and what their security proprties are.

jasonjgw: The same would need to be done for accessibiltiy in order to make the same determinations about the accessibility of an application.

matatk: That analogy segues into something else that a11yEdge (and others) have been looking at...

janina: Machine-readable metadata on the accessibility of a site (at a well-known URI).

janina: _People_ need to be able to read this, but machines also need to know what ATs etc. are supported.


matatk: We reviewed this spec and then realized we could use it for common "destinations" on sites, as per the planned Adapt spec (informed by COGA TF).

matatk: Then the Edge CG realized they could use it (as above).

matatk: We also recently recieved a proposal for a well-known URL for the accessibiltiy statement from outside of W3C.

matatk: Well-known things are a building block (Janina gives DNS/port 53 as an example)

matatk: Common "destinations" on sites: https://www.w3.org/TR/2022/WD-adapt-content-20220609/#values-0

jasonjgw: Taking up a previous point about being able to submit a web content accessibility issue to the creator (e.g. from an email address). But we could get much more sophisticated and report, e.g. a problem with a particular button on a page.
… ...and how to automate it so the user doesn't have to fill in a lot of extra information.

matatk: https://www.w3.org/TR/reporting-1/ - we discussed things with this team last year; there was interest on both sides; need to take it forward!

matatk: Woudld be great to enable people to automate (accepting the limitations) the scanning/reporting on their own site.

janina: Maturity Model is working on documenting good practice in related areas.
… And there's a breakout on it, on Wednesday, too: https://www.w3.org/TR/maturity-model/

Lionel_Wolberger: Seems relatively easy to register well-known URLs with IANA.

matatk: We need to be able to determine which .well-known URIs are supported
… the current crop of well-known URIs seem to be services that are needed right now
… whereas the a11y use case would involve a URI that might be needed in future.
… for example, the Adapt use case where a person is interested which of these URLs are supported by a site
… Ian Pouncey suggested a JSON that describes the services available on the site


Minutes manually created (not a transcript), formatted by scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).


Succeeded: s/@@/confusion for people to hear something they can't see on screen./

Succeeded: s/struxture/structure

Succeeded: s/and where they came from./and where they came from, and what their security proprties are./

Succeeded: s/I am picturing/Ian Pouncey suggested/

No scribenick or scribe found. Guessed: matatk

Maybe present: Fredrik, Jason, Lionel_Wolberger

All speakers: Fredrik, janina, Jason, jasonjgw, Lionel, Lionel_Wolberger, Lisa, matatk, mitch11

Active on IRC: Fredrik, jasonjgw, julierawe_, Lionel_Wolberger, lisa__, matatk, mitch11, nigel, Roy, theAli