APA TPAC Tuesday

12 September 2023


(I18N, (I18N), Addison, alisonmaher_, Anssi_Kostiainen, benb_, Bert, Bos, BrianE, Fazio, Fredrik, Fuqiao, Irfan, jamesn, Joyce, kakinney__, Kenneth_Christiansen, Lionel_Wolberger, Lisa_, matatk, Matt_King, mitch, nicole, Roy, Shawn(12:00), spectranaut_, WG)
gpellegrino, Irfan, Irfan:, Lionel_Wolberger, matatk, mitch11, Roy

Meeting minutes

Compute Pressure API

<Roy> [2023-09-12 10:03] <Irfan>

<Roy> s/[2023-09-12 10:03] <Irfan> //

<matatk> w3c/a11y-request#53

<matatk> Document for editing: https://docs.google.com/document/d/1io7w3Iu9QSZ-NHfpHwQe-VTGILCL7ckqj8qUMITir4Q/edit?usp=sharing

matatk: The purpose of this specification is how to improve user experience.

matatk: there are accessibility consideration that we have discussed.

matatk: ack anssi

anssik: there is not much to do on browser implementation. UI for reporting is not really a strong use-case but it is a good illustration.

kenneth_Christiansen: explaining examples

there are challenges including exposing global state, can be used for side-channel attack etc

matatk: we want specs accessible to be read. that would help to show people that it is different.

anssik: we will incorporate the required changes in the doc


we have partners like zoom who uses this API. we support use in dedicated and shared workers. we have iframe support

we worked with Privacy Interest Group (PING) to create good mitigations

we believe we have solved the security issues

matatk: I never would have thought that it could be done. it is fascinating

anssik: it is another example how horizontal review can help improving our work

specs is very stable currently

it has passed multiple reviews including google privacy team,

in future we can handle various use cases

anssik: we are open for any further feedback and contribution

matatk: we are equally pleased with this work. like any new tech it has big potential to improve accessibility

is algorithm published anywhere ?

<Lisa_> if there is time should we bring up coga?

anssik: we did many prototyping to achieve this

matatk: what sort of bandwidth did it give you such as displaying "Hello world"

anssik: 30 minutes

we always working to improve the algorithm.

also, it depends on the system capability

mitigations are much stronger what would be needed in real world.

30 minutes was initial phase sending the data and get response. I ahve made few optimization in algorithm. perhaps someone can have better idea infuture

<matatk> https://www.w3.org/WAI/standards-guidelines/

<matatk> https://www.w3.org/WAI/tutorials/

matatk: I wonder if we can find a realistic application for accessibility perspective

anssik: game streaming

anssik: we are meeting on thursday to discuss it more and you all are welcome to join.

RRSAgent: make minutes


Interlinear publications

janina: accessibility is in sad shape for multilingual content
… opportunity: EPub 3.3 is done
… blue sky now, what can we do for TTS (text to speech)? Braille is not so bad
… subject matter examples: religious text, music
… we'll talk to i18n, maybe HTML
… Epub is interested, talking with APA
… translations flow differently
… people are currently hacking, how do we hack less?

<matatk> One example that were shared yesterday: https://www.scripture4all.org/OnlineInterlinear/NTpdf/mat1.pdf

janina: opportunity for curb cut effect, not just for people with disabilities

<matatk> Another example that was shared yesterday (uses a table): https://biblehub.com/interlinear/matthew/1-1.htm

janina: example: interlinear text could be made easier to understand
… modern languages and ancient languages
… different TTS speeds for different languages per user preference

matatk: examples pasted above

addison: by interlinear, clarify a doc with multiple languages?

janina: yes

addison: it's a familiar problem, established in print, there will be interesting challenges in digital
… language tags, other techniques

janina: Irfan is working on pronunciation
… assessment is needed

addison: where looking for assistance or gaps?

janina: knowledge or prior art would be helpful, we're just starting

<Lisa_> example by hand hebrew english https://mechon-mamre.org/p/pt/pt0.htm

addison: I imagine people use existing HTML or Epub structures. Are standards around this lacking?

janina: curb cut mention

matatk: seen PDFs and HTML tables to align things. It gets the alignment but it's hard to read. Maybe something like Timed Text would be analogous

janina: what is the increment that makes sense? word level probably not

addison: and word order varies by language
… so generally want sentence-level alignment
… I started in Bell Labs doing text alignment. It's a challenge, e.g. when starting texts are not yet aligned

janina: we have inline lang, that's about it

addison: that presumes someone has identified the alignment
… can be by sentence, by paragraph; could be by line but word order gets in the way
… so I would think about authoring tools

r12a: introductions
… what are the use cases?

<Lisa_> we can add symbols

janina: we want to improve support for going back and forth between two languages, while learning or improving a language
… we want TTS (Text to Speech) to work better. (Braille is already pretty good)
… we want it to benefit users beyond people with disabilities ("curb cut" effect)
… example: studying religious texts
… we think there's enough with markup and user agents, but we don't have it now
… epub folks are also ready to blue-sky this with APA

r12a: so people can read the other language to understand their own language?

janina: and for language learning

r12a: language learning affects alignment, for example smaller segment alignment for some kinds of language learning

janina: authoring could be flexible to address different goals with similar mechanisms

r12a: and sometimes multiple languages? Example: Tibetan texts

janina: or opera libretti

matatk: summary: good introduction to interlinear, would appreciate info from i18n on prior art later offline

what plans does i18n have for exploratory blue sky, which could benefit from APA accessibility participation?

<r12a> be it useful or not, this may spark some ideas...(?). https://r12a.github.io/blog/201708.html#20190304

<gb> #20190304

addison: a lot of i18n is horizontal review, not blue sky
… we also do language gap analysis

what are the needs for different languages on the need, and how well do technologies support that?
… examples Korean, Ethiopic languages

i18n exploratory work

addison: actual current work: bidirectional language and metadata, could be crossover with APA

r12a: we've been talking with WCAG
… currently recommendations should expand line spacing, word spacing, appears to be based on English or Latin-based languages
… but e.g. Japanese puts space differently
… and some languages don't have spaces between words

<Lisa_> coga and internationalizing https://docs.google.com/presentation/d/1rAukW3tEH9DKW9MdU9RAVgfj8OBckZxo8rZ1BiTOhyU/edit?usp=sharing

r12a: so what are actual readability needs?

coga task force intro

matatk: Lisa Seeman's group is on "Making Content Usable..." doc

Lisa_: That doc is one activity.
… also there's WCAG 3, the next version, which is more flexible (than 2.x) to do this kind of thing
… how much is enough? is it doable?
… want to work closely with i18n, not as an add-on later
… want to develop the guidance e.g. simple text and voicing, how do a sample of 5 or 6 languages for conditional tests
… perhaps opportunity: cognition can be a barrier; in parallel language knowledge can be a barrier for users

r12a: The list of languages for rollout in stages. Depending on what you're recommending, e.g. sentence length
… then the choice of language examples will vary by the goal
… but if it were more about typography then a different set of languages would be pertinent
… Going with 4-5 initially could build barriers later
… So recommend grouping the languages around criteria, likely for later success

joyce): those kinds of rules for
… good automatic translation

Lisa_: big overlap between accessibility and translation

janina: Wrapping up for another call, this was good for queuing up next conversations

matatk: scheduling Thursday or Friday this week to do

addison: "object permanence" we exist when we've left the room, we're available
… earlier is better

EO - Maturity Model and Adapt

matatk: introducing two specs that APA has been working on
… marketing the maturity model
… and adapt
… anything EOWG wants to raise?

matatk: round of introductions


<matatk> https://www.w3.org/TR/maturity-model/

janina: We might have some time on this, but it's getting attention frequently so maybe sooner
… frequent question: why another maturity model? We have answers which would benefit from communications

<matatk> Overview breakout tomorrow: https://www.w3.org/events/meetings/ae47e209-26bf-44f3-8ac8-7936879c979d/

janina: Adapt: aim is for people to participate more fully, related to symbols
… Adapt might be sooner

<matatk> Adapt breakout tomorrow: https://www.w3.org/events/meetings/89a19590-3b11-41d1-8129-c03c870f6c29/

Maturity Model Messaging

fazio: many maturity models around, they're often sales tools, not developed with W3C way of developing
… so it makes sense for W3C to offer
… it's gotten input from around the world, and with participation of people with disabilities
… free for use

janina: identify problems sooner
… in all technology areas, customer facing or internal facing, everything is a web page, which makes importance
… expect readiness before next TPAC
… tracking status is a part of it

matatk: There are two others that I'm aware of that people will be asking about, contrasting the W3C model with: ISO's [I don't have a link] and the UK Business Disability Forum's https://businessdisabilityforum.org.uk/knowledge-hub/resources/tech-taskforce-accessibility-maturity-model/

matatk: past question received: what is difference from other past maturity models? summary of answer above
… the UK Business Disability Forum has another maturity model, touches some points that Fazio mentioned, we can anticipate such questions

fazio: Yes we've been getting such questions
… ISO is behind paywall, and uses their kind of language content
… we've incorporated from these sources
… re measuring over time: there's need for evidence of claims, this should help
… US context: how to demonstrate "readily achievable"
… entity can show the government, and can also show people (the public)
… AAPD, disability index, companies love to announce 80% or more achievement
… similar opportunity for this maturity model

Lisa_: a few years ago she worked on UN based G3ICT, not sure about distribution since then

fazio: they're more focused on universities and Smart Cities; Fazio is in touch; they don't overlap (with this maturity model effort)
… also differences in business goals

<Lisa_> i think it was focused on smart cities

BrianE: A big question will be why is W3C doing this. Do you already have rationale prepared?

fazio: yes, somewhere in the written it has the why question

kakinney__: context: hasn't yet gotten through reading the content of the model
… re this model's spreadsheet, comparing with another org's scorecard, both are Excel
… putting the report result on a website might need to bump up in priority
… akin to accessibility statement builder

fazio: or the EM conformance reporting tool

kakinney__: what's tangible, can hand to people in orgs with less accessibility knowledge

fazio: it's jargony right now, still working on, identifying what phase you're in
… we're iterating, want feedback now on the spreadsheet

janina: and the spreadsheet format is temporary in this iteration

kakinney__: feedback on the spreadsheet could go in the wrong direction

fazio: we have a statement saying so

matatk: above could be a good point of collaboration with EOWG

shawn: recall the equity group was interested it becoming an equity maturity model

fazio: it's designed to be extensible
… tbd if guidance on how to do that will be included

shawn: both activities are occurring in W3C, so encourage coordinate sooner than later

fazio: difficulty to get done current scope, so this group has needed to stay focused
… happy to work with groups who wish to extend

shawn: don't want two groups working on two similar maturity models, yet different

fazio: yes let's talk and join forces, and meanwhile the group has held our feet to the disability scope

shawn: request Roy make the contacts


Lionel_Wolberger_: WAI-Adapt continues accessibility work of decades, shout out to call participants' long-time contributions
… Adapt is about personalizing an experience beyond what content creator had in mind
… especially for people with cognitive disabilities
… think of icons and their accompanying text
… also think of pictures in text messages
… now ready to go to technical Recommendation: a way to semantically indicate a symbol
… drew from AAC
… and we have consensus from the AAC community
… this can be a huge curb cut. Some need, all benefit.
… paper handout today
… the word "symbols" was carefully chosen to be understood by some, but also is overloaded term in a tech professional context e.g. halls of TPAC
… The rendition of the symbol is internationalized

fazio: Accessibility Association of Europe (AATE), is doing a lot with symbols, connect with Dominic

matatk: We have a demo tomorrow
… including the authoring side
… have mechanism for mapping between sets, but don't have the actual mapping yet
… two sides of the paper handout show two symbol sets of the same four step example: "My Favorite Recipe Video (chapter list)"

kakinney__: clarifying the identifiers on the handouts of symbol sets: ARASAAC and Blissymbolics

shawn: actually I OKed the W3C logo and handout, but not all of the content

<Zakim> shawn, you wanted to ask Equity maturity model and to say IF people are OK delaying lunch - brief intro of other WAI-Adapt modules?

shawn: todo includes the handout onto the overview page so we have it digital
… remind us the other planned modules

matatk: A range of things, in terms of capabilities not modules:
… things that COGA has identified as problematic, but solvable with metadata
… looking at simplification
… and distraction

janina: and standard destination

matatk: we've stumbled on solving navigation ease, e.g. logging out
… machine can determine based on standard URLs precedent
… might not be in this spec but would build on others

janina: metadata would be at the element level, this is important. Today we have it only at the page level.

matatk: thank you for thoughtful questions, looking forward to continued scrutiny and working together

EPUB 3 Accessibility

<AvneeshSingh> https://github.com/w3c/epub-specs/wiki/Image-Missing-When-Described-in-Context

APA Use Case: §image management when a description is already part of the text content


matatk: so the issue is about images described in context; if we completely hide it to endusers it's a problem, we should find a solution for telling that the image is described in context
… a new proposal may be to add a role to say that the image is not decorative, but is described in the context

janina: Not APA consensus, but we discussed it and had several thoughts. One of the issues was that an appropriate description of an image depends on the context.
… E.g. Looking at an image from a theatre costume design, or set design, perspective.
… We also found that we would want to be able to reference the image in order to share it with others.

matatk: everybody agreed that we don't want to hide the image, so to be able to point at the image

CharlesL: We're here because publishers are asking for guidance. They're either putting "image described in surrounding text" a lot OR if the image is described in an extended description, they're saying "image described in extended description linked below".

CharlesL: This is happening in books that are going live, and people are wondering if it was acceptable.
… It would be ideal to come to a solution to this that is not hard coded into the alt text.

janina: We didn't get into the mechanics, but that makes sense.

matatk: I see possible issues with the abuse of this new role, telling that every image is described in surrounding text

<Bill_Kasdorf_> +1 to @matak

<gb> @matak

matatk: (Hopefully done a reasonable job of putting across Jason's concern.)

Bill_Kasdorf_: Agree with what you just said. In my experience, surrounding text is more likely to highlight the image than describe it. Most important thing for complex images is the extended description.
… Both of the things that CharlesL said might be sub-optimal, but pointing to the extended description is likely the best way.

CharlesL: I've also seen publishers put <figcaption>s below the image. E.g. a complex table (that's too complicated to render).
… The caption doesn't want to be repeated in the alt text description. What would we put in the alt text? There would be an extended description (that is the actual table) that's linked.
… (Publishers are doing this; maybe a better concrete example.)

Joyce: The figcaption is info for everyone to better understand the image. The alt text should be for the SR user. I ask: how could I refer a sighted person to that image? Look for the image with "the table of cars sold".
… So the alt text is about sharing/working with people.

jasonjgw: In the example that CharlesL gave, publshers shouldn't be putting tables in images (which CharlesL ACK'd). If they do, how does one know that the image is not a graph? The only way to do that is to put something in the alt attr that says it's an image of the table. Say what the image represents in a way that's clear for the reasder.
… That would meet guidance and best practices, so we can already handle this with what we have. There would likely be resistance to defining new roles. Then all the accessibility guidance would have to be modified to reflect this. Long-term thing.

George: If we do nothing and null alt text means the image is hidden, then I think we have a binary decision, where if it's decorative, alt is null, otherwise all the time, we need alt text. Even if the image is described in surrounding text.

<Bill_Kasdorf_> +1 to George

George: I do think that means that all of our guidelines need to change to reflect that position.

Markup in Chapter titles

<CharlesL> +1 was thinking the same thing.

AvneeshSingh: EPUB refers to/is based on the latest version of HTML.

gpellegrino: In Italy there are experiments into using symbols in digital books. There are IP problems with some of the symbols.
… There are different schools on how to apply/how much to apply the symbols. There is not so much scientific agreement on this.

<Bill_Kasdorf_> Are the symbols in unicode? Could they be?

gpellegrino: The books are made in fixed layout format.
… This is not the best format for accessibility, as can't be adapted so much. The symbols normally appear on top of different words. I see a possible issue with reading systems in the EPUB world.
… It's not only rendering HTML. Adding symbols would have to repaginate the document.
… Microsoft Inclusive Reader was developed for EPUB, now applies to HTML, and is already implemented, but only uses their collection of images.

Expert handlers/embedded media


janina: Some kinds of objects we put into books (I wrote it for music, but could be any number of disciplines) we're unlikely to cover well in UAs, but specialist reading tools exist. E.g. there's music software that gives a high level of functionality.
… Being able to hand over to the specialist viewer app, and back, at the right places, would be very helpful.

janina: There are many ways, e.g., that we would like to navigate musical content; applies to other content too.

<AvneeshSingh> w3c/epub-specs#1227

AvneeshSingh: The above issue talks about including MusicXML in EPUB. EPUB is XHTML so can include other XML markups.
… I don't see a challenge on this side, but more on the browser side.

janina: I see the issue as bringing in the code that you need for the specialist feature set at the time, and then switch/hand back to the browser at the right time.
… Like iframes but with more smarts.

AvneeshSingh: Like MathML?

janina: Not sure we've decided on this yet; there is a lot of open source code out there.

AvneeshSingh: We used to use the same appraoch for MathML before UAs started supporting it. We could adopt a similar approach.
… What's the ask? Are we looking for browsers to support certain XMLs natiely, or polyfills?

janina: I don't thing UAs are going to support all of these natively; niche user groups.

<wolfgang> s /natiely/natively/

AvneeshSingh: What are we looking for in the spec to address this? New attributes/elements to identify these types of media?

janina: Yes. Particularly means to hand off control and get it back.

matatk: Once we have clarity on how to get content into EPUB docs, we could create a proof-of-concept browser extension to test the hand-off (there are ways to interface with native apps but not sure how smooth the handoff would be).

AvneeshSingh: What should our next steps be?

CharlesL: Make an example document containing these types of content and go from there?

janina: Last we talked about this "expert handlers" breakout 2017 - the room was full!

George: One approach we might follow is that of Igalia which is building the code for Eelectron, and then offering it to the browser for inclusion in their codebase.
… This means the codebase as developed could be used as an extension but eventually contributed back to the browser for its core code.

janina: Agree, there are lots of use cases for this in music alone. Lots of educational possibilities.

George: I can see many areas where we'd love to see it in browsers.
… Maybe a process for a company who's engaging in the form of software development would add more weight to this, and help the browser folks keep track.

matatk: +1 to George

matatk: I'd like to prototype things to see where the gaps are, but we need some way to get professional code written and build these sorts of relationships.

janina: The code for Muse Score 4 is open.
… What is not there is the kind of things you'd want as a learner of music, such as setting A and B points and setting the tempo of the music, because when you're a learner, you want to go slowly, and then get faster.
… This is an external process to the browser.

matatk: I think a lot of this might be do-able with Browser Extensions, but a challenge would be ensuring the rendering in the browser is up to date with where the app was when it was closed.

jasonjgw: One of the use cases is given the graphical and auditory capability of the web these days and the ability to compile to WASM, both music programs and chemistry markup editors could be brought into the browser. Some office programs have already made that transition.
… How well is that going to be supported for all of the accessibility services?

matatk: Agree. I like to use mobile apps as expert handlers. Not sure how well WASM (and UI adaptations) would work on mobile.

jasonjgw: The external app handover situation is still the simpler one.
… Especially if you can get the reverse direction communication too.
… Editing needs to be accessible too! That's why I'm worried about the case of in-browser native apps.

Symbols markup revisited

George: With DPUB ARIA roles, we could associate symbols with things like chapters.

janina: We need to be able to use the registry's symbol codes, so that the right symbol could be produced.

matatk: Could we vary the symbol with the DPUB ARIA approach?

George: Sometimes H1 is chapter, sometimes H1 is part, H2 is chapter. In either case, you'd use the role doc-chapter.

matatk: Our idea is to mark up the concept that is reflected in the chapter heading, hence the need for variable symbols (not just the concept of "a chapter")

George: Different types of books would have different types of chapters; wouldn't have roles for each.

matatk: We would be wanting to use our adapt-symbol attribute to provide the concept for the chapter.

janina: We could also refer to the doc-chapter role and render a symbol that says "chapter" too

matatk: Really cool that we have the idea of structure from George and content from us. Could have a UA that supports both.

janina: You could also reassemble the content on the fly.

Interlinear publications

matatk: We spoke with i18n about this earlier.

janina: This exists in multiple ways, and can be described in multiple ways.

janina: We're talking about better handling of content in multiple languages side-by-side with some form of synchronization.
… Could be word-by-word, or line-by-line. Could be studying an ancient text, or an opera libretto.

janina: i18n thought sentence-level may be most effective.

janina: If reading a book in multiple languages, there may be different speeds needed for the TTS in each language, for example.

Lionel: We raised this last year; since then I got a little more insight. Turns out it's not just words being linked across lines. Comics are a similar thing: the text and the drawing are as related as sentences in two different languages.
… We need a semantic method for relating two things that are meant to be rendered together.
… We've seen examples using HTML tables but they're not appropriate.

One example that were shared yesterday: https://www.scripture4all.org/OnlineInterlinear/NTpdf/mat1.pdf

Another example that was shared yesterday (uses a table): https://biblehub.com/interlinear/matthew/1-1.htm

matatk: Again makes me think of Timed Text, but the axis isn't time.

Lionel: +1, but synchronizing experience, not time.

Lionel: Comics again: "if you're dealing with this dialog, you want to be dealing with this panel"

George: Was going to mention comics and manga.

matatk: I remember reading comics when I got an iPad and they had ways to help zoom into the comic and navigate between panels. Any known standards?

George: I am aware of work going on on it, and it is an interesting problem, and being worked on.
… Would need to get more involved in order to find out the status.

Lionel: there is a known file format CDR/CDC [? may be wrong - scribe]

jasonjgw: Work on Ruby may be related?

jasonjgw: There's a Ruby base and Ruby text, and maybe if that info is accessible, similar mechanisms could be used for what we're discusing (not the same markup, but from an accessibility PoV they could turn out to be similar).

wolfgang: If you want to bind things together in XML, you make a parent element and group the subordinate elements. We could group elements and apply the @lang attr and say whether the contained elements are sentences, paragraphs, or other linguistic divisions.

<gb> @lang

George: That's how it works in SMIL.
… This sort of navigation is well implemented in DAISY readers.
… The difference is that audio is king in DAISY, and text is the boss in EPUB.

matatk: Earlier, I was thinking about the idea of a <picture> element for text, too :-)

Multiple tracks of sign language

janina: This came up in RQTF. A matter of keeping video synchronized at some level, and keeping the signers pinned [as covered in the RAUR -Scribe]

jasonjgw: This was multiple tracks of sign language for different sign languages IIRC.

Joyce: Has anyone talked to platform vendors as to if they have thoughts on that. We can set our language. Can we set a sign language as our preferred language in an OS?

janina: There are language codes for different SLs

Joyce: Can they be set in an OS?

janina: We found this in the MAUR - https://www.w3.org/TR/media-accessibility-reqs/ - which we'll be updating with MEIG et al soon.

jasonjgw: When setting up an OS, specifying language and region, that may be enough to infer what the sign language setting would be (though it may not be enough, it might work to a degree).

RAUR mentioned above is https://www.w3.org/TR/raur/

Making UAs better UAs - Footnotes


janina: Several cases for how we might want to access footnotes.
… Inline; Jump to footnote, and then back to content; [other modes of access too, but the point is we need flexibility on how to access them]

jasonjgw: There could be multiple sets of notes in the same document, e.g. translators' notes (about translation issues); author's notes (traditional/scholarly notes); might want to access one or other set differently.

jasonjgw: Even in the handling is the same, the ability to distinguish between the series of notes is important.

janina: And that's metadata we don't have.

George: EPUBtest.org tests various UAs reading systems for EPUB content. We're in process of updating our test books. We'll be adding footnotes and MathML testing to the fundamental books (previously they were in the experimental/other books).
… doc-footnote and doc-endnote DPUB-ARIA roles included.

George: Different readers have different ways of treating (rendering/interacting) with them. We want to test the various systems to see what their UI is. At the end of the footnote we have a link back to the content.
… Various SCs around footnotes.
… This brings up the need for a "Back" button, which is not commonly implemented. It's a burden on the author to implement this via back links.

matatk: Challenging when a "footnote" is referenced from multiple places, so a Back button would be good.

George: Glossary references may have that issue.

jasonjgw: An example of this may be a note in a table, where multiple cells reference the same note.

George: Fundamental books are for things that are commonly implemented. E.g. MathML used to be in the experimental book, but now is making it into the fundamental one. Back links would likely be in the experimental book.

George: A problem is following a link from the ToC, pressing the down key, and then the screen reader starting again from the top of the document; it's a focus problem.
… Some readers cope with this, but some don't.
… It would be better to be able to share how the ones that made it work actually made it work. Thorium has done it, for example (which is open source).

matatk: It could be a case of adding tabindex=-1 to the element and then .focus()ing it? (This is what the Landmarks extension does.)

George: Please could you write that up?

matatk: Yup!

Exploratory issues

Bill_Kasdorf: Locators. Originally this would be pages; the page breaks could be included in an electronic copy. But now there are lots of things that don't have a print version, and the concept of "page" is fluid.
… When we ask the publishing community what they want, that comes up a lot of the time.

George: To add to that, the absence of page navigation in books that have no print equivalent, is a huge issue in the scholarly world where you have to make a reference.
… People have to grab a PDF version of a fully accessible EPUB and use _that_ for citations, which is sub-optimal.
… The locator needs to work consistently across reading systems that works consistently across reading systems.
… E.g. How to apply this to APA.

matatk: Was wondering about IDs, but are some too long?

George: The problem is the book gets re-issued, and you can't depend on IDs staying the same.

jasonjgw: I made references to sections or chapters in works. That's not a complete solution because you might want to refer to something at a finer level of granularity. In legal texts it's common to have numbered paragraphs.
… If the text hasn't changed between editions it'd be nice if the references to paras continued to operatre despite other changes to the surrounds. In some cases they're moving to para numbering.

<wolfgang> s/operartre/operate/

Bill_Kasdorf: Agree regarding legal and reference publishing, which does have that granularity in the markup. But the vast majority of content doesn't have that kind of structure. Another issue is indexes. Back of book indexes point to page numbers.

Bill_Kasdorf: Modern readers might wonder what the point of an index is—it's a conceptual overview of the contents of the book (can't just be replaced by search).

Bill_Kasdorf: This is an important accessibility problem.

*general agreement*

Bill_Kasdorf: Suggestion regarding decorative images: clarify that a decorative image "does not convey information"

George: The guidelines actually mention "described in surrounding text" use a null alt attribute.

Joyce: in a book, a photo may not convey meaning, but could convey emotion.



<Fredrik> @Lionel: I am happy to back you up as scribe if you want.

<gb> @Lionel


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

<spectranaut_> updated link: WICG/proposals#112

Discussing Accessibility (ARIA) Notification API #112

<gb> Issue 112 User Need 9: Any deaf or hard of hearing user watching captioning or audio description needs to be confident it is synchronised and accurate. (by RealJoshue108) [enhancement] [RAUR]

Link, WICG/proposals#112

matatk: Is it fair to say the scope is nonvisual text as it relates to screen readers?

Doug: Yes.

matatk: A concern that developers might mix this up with other types of notifications
… We did see it as imperative announcements

Matt_King: It's an assistive technology notification

<Fredrik> How about "nudgifications"? Too cutesy?

matatk: Developers may think they will find here the accessibility of notifications in general, e.g., the accessibility of a toast notification; it is clear that is not in scope, to us, but we are concerned
… that others might be confused

Matt_King: Proposing: AT Notifications?

janina: AT is very broad

Matt_King: Any AT relying on an accessibility API will be relying on this

jamesn: Propose, put off the naming discussion

jcraig: I share the concern. The name 'ARIA notifications' did not seem best to me, either; it just happens to be a notification that ARIA group discussed
… there is precedent for this API in every platform accessibility API

matatk: Was the term 'announcements' considered?

aaronlev: We are open to considering other names.

matatk: Does this need to support braille?

jcraig: Any speech notification that voice gets for processing should be rendered on an associated braille display (if present). the portion NOT on the table is that braille and speech notifications would be identical in v1; v1 not planned to include a braille-specific variant notification.

aaronlev: We expect to hear from braille users, as the experience varies.
… though the braille display experience is secondary to the voice experience, ARIA wants to get that aspect right this time.

Fredrik: Users have varying expectations regarding notifications

Doug: Would it help if the notification carried more information-- that the notification should flash, should ..?

Fredrik: I am asserting that we need user agency, user control over such notifications

Doug: The AT should take responsibility on how best to present the data to their users

<Fredrik> q/

jasonjgw: the braille experience of notifications will likely improve with the imminent release of several multi-line braille displays, if the teams working on that experience would put more attention on it.

Guidance on appropriate use of notifications

Matt_King: When this is published and people are coding according to this API
… ARIA will be pleased to broadcast when those drafts are in place and encourage APA's feedback at that time
… specifically, ARIA will seek APA input on that PR

Doug: MS has a 'confirmation of action' document
… to encourage the handling of status consistently
… that type of proposal could accompany this proposal
… a guideline being, just because something changes doesn't mean you have to get the attention of the screen reader user
… In addition, the vision ability varies and can affect your choices
… on the AT side, for example, AT might cater to a low vision user in such a way that fewer announcements are made, selecting based on notification ID

matatk: APA is very interested in raising awareness that not only low vision people are using screen readers
… people with cognitive disabilities often use screen readers as well

aaronlev: The process of writing the documentation can be SO HELPFUL to deeply understanding requirements
… We'd love to see people write up, how they would like notifications to work (from the user point of view)

Matt_King: Gives +1 to that

<Fredrik> How about callingthem AT Whispers?

<Zakim> jcraig, you wanted to mention notification API usage for out-of-view notifications for lowviz zoom users

jcraig: Include the variants of users that will be using this
… Nice to have a history of notification. Reading the history of notifications can be very useful.
… Another strong aspect is that the notification is tied to a particular element
… this permits the association of bounds. An element out of viewport could handle such a notification differently (since it is offscreen)
… in general, this underlies that these are AT notifications, not just screen reader notifications

nicole: The focus of the API seems to be on visual changes. What about for a display: none element?

+1 to jcraig about viewport-based awareness for low-vis users

aaronlev: Relevant to that use case

jcraig: Does this deprecate live regions?

<Fredrik> Could we have an offensive level of live region too?

aaronlev: (aside: back when we defined 'polite' we also defined 'rude' in live regions)

The pronunciation TF is looking for feedback from platform and AT vendors on two proposed approaches: https://github.com/w3c/pronunciation/wiki/Re:-AT-Vendors


Pronunciation in HTML feedback requested

matatk: The pronunciation TF is looking for feedback from platform and AT vendors on https://github.com/w3c/pronunciation/wiki/Re:-AT-Vendors
… [1] AT will process pronunciation information from the accessibility tree (AxTree) provided by the browser.
… [2] AT will parse the SSML-based pronunciation information from the DOM, directly.

Single-attribute Approach has bene implemented by Texthelp SpeechStream and Pearson TestNav on following URLs, https://www.texthelp.com/en-us/products/speechstream/


matatk: Note that we are not suggesting that these attributes be applied everywhere; they are meant to help when an author wants to point to correct pronunciation

aaronlev: Large companies like mine will see this as a hard sell, without a clear business case

jcraig: We see pauses in speech jobs associated with emphasis, for example, is one of the challenges here
… We do see a trend towards an API supporting some type of, 'for this string, use this IPA (int'l alphabet) string to vocalize'

matatk: We found use cases from education exceeding the use cases from ARIA
… we feel pronunciation is being handled now, we'd like more visibility to that

jcraig: Some SSML is being used in some settings
… a lot of variation as the space is complex (browsers, voice engines)

blue sky plans

<jamesn> 1.3 - 2 major features

<jamesn> * Braille (label and roledescription)

<jamesn> * Annotations (comment, suggestions, mark and multi-id aria-details)

<jamesn> 2024 - targetting the following

<jamesn> * aria-actions (secondary actions)

<jamesn> * listview

<jamesn> * notifications (not ARIA ...)

<jamesn> * aria-modal changes for islands of content

<Fredrik> We care about most things.

jamesn: Reviews the list of proposed ARIA major priority areas

WAI-Adapt Symbols module, a small handout showing it

matatk: Demonstrates how symbol markup is easily supported by an authoring tool

jaunita: Do Asian languages, that are based more on symbology, weigh in on this?

<Zakim> jcraig, you wanted to suggest unicode adoption and to suggest ruby w/unicode (same feedback I gave at the 2019 TPAC in Japan) and to also share a new idea... custom font until the unicode implementation happens

jcraig: I saw a different version of this demo at TPAC in 2019. I gave this same feedback then.
… Bliss was first proposed for Unicode in ~1990, but it's not there yet. Why not? If you want to move forward, you need to clear that roadblock.. They need to complete that process to really cement this.
… Unicode in a Ruby line box would be ideal.... In the meantime, you could work it into a custom CSS font as a polyfill and start building public support as justification for the Unicode+Ruby implementation.
… I feel it needs to be in unicode to become universally adopted

matatk: Bliss is making progress into unicode, they are always 'three months away'
… the missing piece is, at the user-agent side, to take the concept (in this case an attribute, or perhaps as you are proposing a unicode) and map it to different symbol sets

jcraig: that could be handled as an ARASAAC or Bliss font on the unicode

Lionel_Wolberger: Nice idea. One issue: Fonts are not normative.

<jcraig> s/To simplify my comment: this might be better handled as a font./that could be handled as an ARASAAC or Bliss font on the unicode./

Could we build symbolic annotations with existing Web standards? w3c/adapt#240

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


Failed: s/[2023-09-12 10:03] <Irfan> //

Succeeded: s/PING/Privacy Interest Group (PING)

Succeeded: s/speeds/TTS speeds/

Succeeded: s/internlinear/interlinear/

Succeeded: s/quicker/sooner/

Succeeded: s/Maturity Model/Overview/

Succeeded: s/subtopic: Maturity Model/subtopic: Overview/

Succeeded: s/international/internationalized/

Succeeded: s/inot/into/

Succeeded: s/surrinding/surrounding/

Succeeded: s/<figgaption>/<figcaption>/

Succeeded: s/doens't/doesn't/

Succeeded: s/reisstance/resistance/

Succeeded: s/borwsers/browsers/

Succeeded: s/)l/)./

Succeeded: s/Onxce/Once/

Succeeded: s/@@/Igalia/

Succeeded: s/comppile/compile/

Succeeded: s/woudln't/wouldn't/

Succeeded: s/managa/manga/

Succeeded: s/kown/known/

Succeeded: s/usd/used/

Succeeded: s/accessibilty/accessibility/

Succeeded: s/abilitiy/ability/

Succeeded: s/preveiously/previously/

Succeeded: s/liekely/likely/

Succeeded: s/hs/has/

Succeeded: s/acorss/across/

Failed: s/operartre/operate/

Succeeded: s/topic: AIRA/topic: ARIA/

Succeeded: s/Matt_King: Is it fair/matatk: Is it fair

Succeeded: s/jamesn: I share/jcraig: I share/

Succeeded: s/will likely improve/will likely improve with the imminent release of several multi-line braille displays/

Succeeded: s/... the braille experience /jasonjgw: the braille experience /

Succeeded: s/will be rendered/should be rendered/

Succeeded: s/associated braille display (if present)/associated braille display (if present). the portion NOT on the table is that braille and speech notifications would be identical in v1; v1 not planned to include a braille-specific variant notification./

Succeeded: s/Topic: Pronunciation in HTML feedback requested/Subtopic: Pronunciation in HTML feedback requested

Succeeded: s/To simplify my comment: this might be better handled as a font./that could be handled as an ARASAAC or Bliss font on the unicode

Failed: s/To simplify my comment: this might be better handled as a font./that could be handled as an ARASAAC or Bliss font on the unicode./

Succeeded: s/Blissymbolics is on its way into Unicode/Bliss was first proposed for Unicode in ~1990, but it's not there yet. Why not? If you want to move forward, you need to clear that roadblock./

Succeeded: s/this implementation could be worked into a custom CSS font/Unicode in a Ruby line box would be ideal.... In the meantime, you could work it into a custom CSS font as a polyfill and start building support about the Ruby implementation./

Succeeded: s/I saw a version of this demo Symbols in 2019./I saw a different version of this demo at TPAC in 2019. I gave this same feedback then./

Succeeded: s/support about the Ruby implementation/public support as justification for the Unicode+Ruby implementation/

Maybe present: aaronlev, anssik, AvneeshSingh, Bill_Kasdorf, Bill_Kasdorf_, CharlesL, Doug, George, gpellegrino, janina, jasonjgw, jaunita, jcraig, joyce), Lionel, Lionel_Wolberger_, r12a, RRSAgent, shawn, wolfgang

All speakers: aaronlev, addison, anssik, AvneeshSingh, Bill_Kasdorf, Bill_Kasdorf_, BrianE, CharlesL, Doug, fazio, Fredrik, George, gpellegrino, jamesn, janina, jasonjgw, jaunita, jcraig, Joyce, joyce), kakinney__, kenneth_Christiansen, Lionel, Lionel_Wolberger, Lionel_Wolberger_, Lisa_, matatk, Matt_King, nicole, r12a, RRSAgent, shawn, wolfgang

Active on IRC: aaronlev, addison, alisonmaher_, anssik, AvneeshSingh, benb_, Bert, Bill_Kasdorf_, BrianE, CharlesL, Doug, Fredrik, gautier, George, gpellegrino, Irfan, jamesn, jasonjgw, jcraig, kakinney__, Lionel_Wolberger, Lionel_Wolberger_, Lisa_, matatk, Matt_King, mitch11, nicole, r12a, Roy, shawn, spectranaut_, wolfgang, xfq