Meeting minutes
Unblocking the WAI-Adapt Content Module 1.0 CR
*Group introductions*
<plh> Philippe Le Hegaret, W3C
janina: Our goal is to come up with a plan to get Adapt to CR soon. This is transformative technology. There is nothing mandatory in the spec, except that if UAs implement one attribute, they must implement all values of it (that's the only 2119 MUST).
… We know that we are going to have to have a second CR, as we are following the HTML spec and using data-* attributes for the first iteration.
… We're talking with WHATWG later today, and will be via GitHub after first CR, to request attributes/a prefix.
… We're also working with an external organization (Blissymbolics) to create a W3C Registry, but that is separate to the Adapt spec.
<plh> Feedback from the Director on CR request for WAI-Adapt
janina: We thought we'd cleared all issues with TAG, and would like to know more. Hopeful we can come up with a list of things to do that will satisfy everyone.
Rossen_: From TAG's point of view, we apprecaite your time and patience working with us. We closed the issue earlier this year and intended to close as unsatisfied with the current proposal. We thought we provided clear feedback, but happy to go over it here.
… However, as we forgot to add the label 'unsatisfied' this lead to confusion, and why we're here today.
janina: We want to ensure you end up satisified, as this will be transformative for accessibility, and a piece of wider applicability.
JudyB: Could someone recap the timeline since the issue went to the TAG and whether the current state in GitHub had been actively communicated to APA?
<Rossen_> https://
Rossen_: That issue was posted 2020-02-19.
Rossen_: It was later when the explainer was made available, and then in September we started providing technical feedback.
<Zakim> MichaelC, you wanted to comment on explainer issue (if relevant)
JudyB: I understand the TF was working on the spec during this time, and was unaware that the TAG had feedback.
MichaelC: We wrote an explainer intended for the public to explain what we're doing, and gave that to the TAG. We spent some momths reformatting this into a format that the TAG wanted; this was a process issue that held us up.
… It was hard to know what to do with some of the feedback.
janina: It struck me as not a technical problem, but more a quesiton as to who's going to implement it.
Rossen_: This is a wonderful set of problems that should and must be solved. We have no objections as to if those problems are to be solved. It's the _how_ the current spec proposes to solve the problems.
… A lot of the spec is modelled after ARIA, which was based on existing APIs such as MSAA, and largely intended to be consumed by screen readers.
… These attributes service a wider range of consumers, and it's not cldar that those consumers have been brought in to the design process as stakeholders.
… We propose to split into different parts and tackle them individually with the stakeholders.
janina: The main stakeholders are the COGA TF which was set up in 2013.
Rossen_: E.g. a system that allows the user to opt out of revenue-generating ads will need buy-in from publishers. But the symbols work seems to have a well-defined need and fits into the remit of AT.
… Some of the solutions may not be suitable for standardisation, but could be for incubation and rapid iteration.
… It's excellent work, and rare to receive proposals that take the user needs so far into consideration.
… There's work you've identified that fits into existing technologies, sucxh as media queries.
… That should be discussed with CSS.
<plh> (note: Rossen is also co-chair of the CSS Working Group)
Rossen_: This grouping of problems and technologies that might be put together to address them is to broad to be in one spec. Contraversial ones are grouped with others.
janina: I hear we have no problem on the AAC work, and I think there was another point of agreement. There was a disagreement about distraction, but it was not a technical disagreement. This is entirely optional on behalf of the author.
… In order to move this forward we need (1) content that's marked up and (2) UA support. The US gov's access board has agreed to add symbol markup to their form.
janina: They are aware of distractions too, and so there _are_ other use cases for distraction.
<Zakim> MichaelC, you wanted to say architecture view vs working on and to say how to submit media queries and to say a11y incubation / urgency
MichaelC: From an architecture perspective, I see what you're saying; that was not clear from the GitHub issue. Some things you're asking are hard for this group to work on.
… In accessibiltiy, we try to innovate technologies earlier than it's generally done. Partly because there's nobody else to do this incubation, so those of us in W3C try to get together to incubate it.
… We've tried talking outside our WGs but it is hard to get extenal participation.
… E.g. CSS at one point thought this was not related to media queries.
… We wanted to demonstrate the utility of this spec.
<Lionel_Wolberger> matatk: The innovation in Adapt is semantics at the element level metadata rather than at the page level
<Lionel_Wolberger> ... media queries can sometimes be targeted to the element level
<Lionel_Wolberger> ... and we are having those conversations with CSS
<Lionel_Wolberger> janina: We should have architected this further
janina: +1 - we ACK that we have learnt a lot about media queries (for example) during this.
Rossen_: Re-reading the comments; sorry if this didn't come across as intended. We are trying to reach a balance between encouraging your work on these problems. But the bucket of solutions is too heterogeneous. Some may be more CSS-related; some may be ARIA; some may be more suited to incubation, rather than standardisation.
Rossen_: How can we move forward? At this point we have all come to an understanding of what took place and what was intended to be communicated. What do we do next?
Rossen_: Encouraged that you're continuing discussions, e.g. with CSS.
JudyB: What's the normal process for notifying groups whose work you find unsatisfactory? The comment seems to be ambiguous, and the group has continued for many months/years without realising.
Rossen_: The process is expressed in our template. For the filer/requester to specify how/where to get communication. Default assumption is you're communicating over the design review.
… Whomever fiels the issue will get notifications; we assume they'll re-engage with us.
JudyB: Suggest that separately to this, we figure out how to debug the process.
Rossen_: ACK
janina: You asked if we had input from the communities we address. If that wasn't clear in the explainer, we can make another pass. We have better documentation now than we had in 2020. Content Usable is a published Note.
… Interested as to what you think, other than the media queries, could belong in CSS.
<JudyB> [jb: suggests that Team and TAG follow up separately to work out ways for WGs & TFs to get clearer and timely notification if TAG believes that a WG is heading down the wrong rabbit hole.]
janina: Not sure what you think could go into ARIA, as most users are not using assistive technology.
MichaelC: This started as an ARIA module and was not taken further by ARIA.
Rossen_: IIRC that was around 'action'
Rossen_: I took some time to review the current draft.
… (June 9, 2022 WD)
… The first part of the vocab is @action.
… We felt this was closer to actions and capabilities that are exposed through ARIA. There are some that are not (e.g. distraction).
… Agian, this is the basis of our feedback: the set of solutions and problems is very heterogeneous; having them all under one spec, architecturally is very challenging.
… Is @action related to ARIA? If not, then why?
Review comment tracker for WAI-Adapt
Rossen_: Not going in to @distraction more as we think it's a poor choice of proposal. It's hard to think of why authors would want to adopt something like this. I'm not saying there's no subset of distractions that are not ads.
janina: Would a different word help? Nobody is compelled to implement any of this.
Rossen_: If nothing is mandatory, what would the spec serve for?
janina: It serves for the people preparing content for the varied audience facing these barriers.
Rossen_: Why is this not a Note?
janina: E.g. we do have one RFC 2119 MUST requirement. Without this, there would be too much inconsistency in UAs. Whether you implement something is optional, but when you do, you must implement all its features, to provide reliability.
Yves: Sometimes when we give comments to WGs, we don't see anything for months, then recieve a fixed version. It's difficult for us to interact extenively with all the WGs, as they all have different styles of working. So the key here is we need to properly label the issue to reflect the status, so this one's on us. The time between interactions with WGs is entirely up to them.
Rossen_: Difficult to know why groups are silent.
<Zakim> MichaelC, you wanted to pick up on heterogenous
MichaelC: It'd be good to have a conversation after TPAC. Both TAG and APA are HR groups and so we both have this challenge.
… We've not thought of it as a heterogeneous spec; just wanted to surfaxe this.
<JudyB> [JB: recommends that Art of Consensus minimally adds a "message received" step as part of the horizontal review process. In this case a WG continued to work actively on this investing time for a long time w no understanding of the dissatisfaction in their approach. PLH, is this something you could help follow up on, as you're most familiar with those Process implementation details?]
<JudyB> +1 Lionel
matatk: We worked with COGA to address the 'low-hanging fruit' (problems where element-level metadata could solve them) from Content Usable, so that's why we feel the problems are related and involved stakeholders.
Lionel_Wolberger: I monitor for closed issues, but this one is clearly wide open, and that wasn't communicated.
Yves: Agree that the reaosn wasn't communicated in this case.
MichaelC: Lionel_Wolberger or others may not have had visibiliity for this, as it's in plh's tool, but not what Lionel_Wolberger would see.
plh: We're going to make sure it doesn't happen again.
(I'll work with Yves and the TAG to fix the flagging problem)
Lionel_Wolberger: We thank you for seeing the value in the work, and want to find a way forward with you. These ideas have been cooking for 20 years. One stakeholder, Lisa Seeman, has been nurturing them all along.
JudyB: ACK that TAG has a concern with this approach. But as I see the discussion about the intention and the evolution of the WAI-Adapt approach. I saw TAG suggest things like 'this is part of ARIA' but Adapt feel it's not.
… Or TAG feeling customers' needs aren't being met, but Adapt is maybe talking about a different set of beneficiaries.
… It may be a misunderstanding about some things along the way. I have have advocated for real-time discussion that could've addressed misunderstandings earlier.
… Would more technical consideration have resulted in a different solution? If the TAG finds this is not consistent with the principles of the web, we'd love your timely help to move this forward in other ways.
… Can we have more joint meetings?
Rossen_: You're spot-on; we often have people join us in meetings and they're super-helpful.
Rossen_: My understanding is TAG members were working closesly with the group on the explainer re-drafting.
janina: This is a very new community that we've never served before; it's a new area and maybe that's where the misunderstanding arose. This community has been waiting for this work for some time, we need to deliver at least some of it as soon as we can.
janina: As matatk said, there is a huge community out there and we are concentrating on problems we can solve at the moment.
<JudyB> [jb: notes that, for the digital accessibility community, this _is_ actually a big issue, and we would have welcomed being in the room when you were taking this up, and would welcome being in the room to sort through any misunderstandings that might still make this approach work, and-or to expeditiously sort out alternative approaches]
janina: MichaelC mentioned incubation, but historically this approach has been difficult for us. We are working on it with some companies though.
Lionel_Wolberger: There are many barriers to do a separate incubation. The spec doesn't _require_ much but _enables_ us to start doing that incubation.
Lionel_Wolberger: The community has been struggling for decades to get these techniques enabled. We're not making onerous requirements, only offering those who _would_ solve the problems the means to do so.
MichaelC: Re Communication clarity: it wasn't clear to me whether comments were from individuals, or the TAG officially. Some I took as individual comments, and didn't realise there was a TAG position.
Rossen_: I don't believe we provide personal views unless we clearly state that it was personal.
plh: You do have to know who is in the TAG.
MichaelC: We knew the membership, but were unclear on this.
plh: We will fix this.
<JudyB> +1 to Michael's request that this be clearer in the future
PaulG: I've followd the spec and am only now aware of this issue with the spec coming to fruition. I'm wondering if we can ask: is this the right mechanism for the web, rather than 'is this the right audidence'. E.g. CSS prefers-reduced-motion is very broad. There's no prefers-less-capitalism, prefers-less-violence (e.g. for violence survivors' mental health). It's the author's choice to provide this for
those people.
PaulG: But this isn't an extensible approach. It requires a lot of work. Attributes are much more easily extensible.
… Can we agree that attributes are the right path? We could get into arguments about what the right use ases are.
… But we could perhaps at least agree on the right mechanism.
janina: Next steps?
Rossen_: We'll have a meeting and talk to others in TAG, with others welcome to attend.
… You're joining us in CSS WG on Thursday, we can have this as a topic of discusison.
… We can discuss the applicability and potential fit.
Rossen_: On the back of those discussions we'll have a pretty clear path forward as to what the spec would look like, and can go from there.
Lionel_Wolberger: Time frame for the joint meeting?
Rossen_: We can prioritize this. Will get back to you but we'll elevate it.
*APA expresses thanks for the willingenss to work together again soon*
MichaelC: Who has the action to schedule the meeting?
Rossen_: TAG
<PaulG> https://
paul: we have expanded that idea with more of what we want. we have a list of things we want to accomplish, the original aria proposal linked above covered pronunciation, we want to expand to substitution, pausing/break
<jptownley> could someone please enable captions on zoom?
paul: we want to hear from aria what we have brought, and eventually we should discuss the probably contentious issues
<IrfanAli> https://
<PaulG> https://
PaulG: this is the third iteration, we created two proposals originally (one is json, the other is fully expanded attributes with all values are strings -- both map to ...), the aria proposal responded with some ideas, this is a proposal in response
aaronlev: by the way the aria counter proposal came from me and jcraig
the "aria proposal" :https://
PaulG: the way the aria proposal was structured like a dictionary, the first key is the local. I final recognized the local is set by the user, in html the local is inherited. in the ssml spec the lang attirbute is used with a language/local combination. however, in html, you only use the language. the question is who is setting local, the author or the user?
PaulG: if it is the author that sets the locale, the aria proposal needs another way to set the locale,
jcraig: as a clarifying question, the aria proposal uses a pronounciation dictionary. what is the user whats the something else.. is that what you are talking about
PaulG: what if there are multiple "voices" in a document. there are multiple language/locales in the dictionary. from the aria examples... we need clarification about more complication scenarios
cyns_: for example, canadian docs that have english and french
PaulG: another area we want to address, other variants, like historical context
janina: breakthrough on that during lunch, an email I sent was in a spam filter -- so now we can get feedback addison phillips
<aaronlev> are we using the queue or raised hands?
PaulG: the last area I wanted feedback, can a user pick things that are preferential when there are two accurate ways to pronounce something
aaronlev: when it comes to pronunciation, we use language from web content, the locale comes from the user preference
aaronlev: you don't want the accent to change every time you go to a new page
paulg: we have usecases for author intent, related to poetry
paulg: if the locale is not correct, then it might not rhyme, for example
paulg: if the author cares, then the locale should be able to specify -- but maybe the user should be able to override
<jptownley> 2b || !2b
cyns_: my understanding is that screen readers already don't work well with multi language documents, generally
janina: yes that is true
cyns_: maybe this specificity is premature
janina: the primary goal is to support education
paulg: it might not be exactly languages changes, it could be locale changes, it could be historical accents -- if it represents multiple characters or voices that wouldn't be understandable otherwise
matatk: it is not necessarily screen readers, it could be voice agents or other environments. if you think there is something that needs to be in spec in order for screen readers to be able to provide support.
jcraig: please clarify about bad support for language switching, jaws has had language switching for 20 years, voiceover has had it around 5, based on lang attribute. there are additional features related to natural language processing, like if one paragraph is a different language, sometimes the speech can be changed
jcraig: this is key, not an after thought, we don't have page authors not to have to do this for every single word. This is probably going to be used for the entire site, not each page -- big dictionary for each language/locale pair
jcraig: two dictionary for all canadian government sites
<PaulG> https://
paulg: prior art ^
PaulG: this works with site wide dictionaries
cyns_: what are the high level differences between the aria proposal and the link above?
PaulG: the link above uses XML
PaulG: in addition to pronunciation, I have included a model for substitution, say as, pausing
PaulG: there is no good mechanism for substitution for tts and braille
PaulG: so I made one. section "substitution"
PaulG: this is an area where a user can ignore aliases
PaulG: like "world wide web consortium"
PaulG: reading out alias on first occurrence would be good
PaulG: example from university of hawaii, they want to use the correct spelling of the hawaian words, which messes up screen readers, so they use aria-label
PaulG: having a pronunciation dictionary would work for this case.
PaulG: but when the word is completely different, then is should be a substitution
cyns_: (something about reaching out to someone who matatk has reached out to)
<PaulG> https://
PaulG: this is the list of hawaiian words ^
PaulG: moving on to "say as"
PaulG: 10 could be ten, could be one zero, could be binary two, only the author knows the context. maybe machine learning will be better than what is current
<jamesn> (notes that the UH guide above uses techniques not allowed per ARIA)
PaulG: the context will be build from surrounding context.
jcraig: I have a general concern about how complicated this could be... I appreciate the length you have gone to consider edge cases.. like ordinals, how to pronounce as characters instead of numbers -- but in comparison, does solving the edge cases penalize a large percent of the usage. the primary usage should be as simple and effective as possible
<Zakim> cyns_, you wanted to say what about adding support for inline, like <span aria-pronounce="/bæs/">bass</span>
janina: the author mark would only show up where the author needs to be really precise... we are trying to look at it from the authoring perspective, where key pronunciation ambiguities are handled appropriately
janina: the original set of uses cases come from assessment and publishing
IrfanAli: there is a use case document
cyns_: in addition to having a key structure, we should allow inline, like I have an example above
cyns_: content author who doesn't have access to dictionaries could add
<IrfanAli> https://
<cyns_> <span aria-pronounce="/bæs/">bass</span>
janina: our users aren't using aria necessarily
<cyns_> <span aria-pronounce="folio">Foliot</span>
jcraig: it is really had to create the IPA representation of a word, as an author
<jptownley> https://
markku: (I couldn't catch but reallllly wants this) I have a implementation with json, from peirson and text help that we are using
markku: I'm interested in the "aria counter proposal", but I'm concerned with substitution and say as proposals, I don't know where it is going
PaulG: I'm seeing how far can we take this proposal, is this a pattern we can apply to more than just pronounciation
PaulG: the aria propossal is a great idea, I wanted to see how expandable it is
PaulG: intentionally, some of these areas are fuzzy
PaulG: things like pausing are important for markku
PaulG: I need a new notation for this -- something that means a break/pause
PaulG: this notation has not been vetted, needs to be json serializable, needs to not conflict with other parts of the proposal
jcraig: thanks for saying you are testing the boundaries, I'm concerned with abbrev, pausing, and emphasis
jcraig: I didn't see this proposal before the meeting, I'm not opposed to pronunciation used for emoji (?) -- if I just want a pause, when do I need a separate... like break, and "..."
jcraig: I think this is too complicated.
<cyns_> something like aria-pause="250ms" ?
PaulG: I also noticed that the locale is out of place. the pause is not being translated, its not related to the voice pack
<cyns_> or aria-pause-before
PaulG: for emphasis "whisper" I tried to use a different feature to explore the idea of something that did not get keyed to a locale/lan
PaulG: it is lifted out of the first key!
PaulG: maybe that is something worth exploring
jcraig: markku, ellipses already creates a pause? is that not good enough? what examples of a difference
markku: we have notion of both long and short pauses
markku: I go back to being able to specify in ms
markku: also with a long and short, that maps to ms
Matt_King: does the length of pause, long or short, need to be responsive to the users settings -- if I am using a slow speech rate, a short pause might not sound like a pause
Matt_King: where as short pause with a fast speech rate might seem enormous
Matt_King: I think you need long/medium/short and the AT can interpretive
<jptownley> is there an awkward pause
<jcraig> is there a specific use case that could help us understand the need for long versus short?
Matt_King: maybe you can combine "pause" if you want longer
cyns_: markku, users in your scenario, would they know about ms
marrku: we try to simplify the authoring, allow ms, allow predefined
marrku: the students taking the assessment can slow or speed up speach
jcraig: I know it does with an ellipses, at 400 words per minute is shorter that 80
neil: are there settings that say "ellipse" instead of pause?
jcraig: that could be effected by pronunciation settings
PaulG: I thought about beats being abstract, this is a problem we need to keep in mind, could multiple and divide ms based on settings
PaulG: if we go to formal presentaiton
PaulG: the only other thing -- language is constantly evolving. for the past decade, "latinx" was used, now "latin*" is getting used
PaulG: we are trying to create mechanism that allow us to support the change of language
PaulG: thanks for turning up everyone! and following our work!
PaulG: we need some time to digest these comments. we have an issues log:
<PaulG> https://
PaulG: btw we really need linguists!
PaulG: send them our way
Coordinating comment guidance and WG participation responsibility
Note: We are having an informal meeting; will use the minutes to note actions/topics to return to later.
We discussed that some people have problems giving feedback on W3C work (at all). This is a problem we have to address!
Scott suggested making the different feedback optinos bullets in the documents.
Paul mentioned that searching for W3C via a web seach, then trying to give feedback. The word "Feedback" doesn't appear on the WAI page. It's easy to get from the home page to the historic mailing lists, but then unclear as to what to do with that.
There are a confusing array of emails for feedback on the WAI site.
Paul mentioned that old documents have (sometimes hard to find) email addresses - are those addresses still monitored?
We discussed the importance of people articulating their access needs, and us taking steps to meet or negotiate them, and us being clear to communicate when we are unable to meet (or understand) the person who is giving the feedback's access needs.
Delays in our response may be because we're working to access the feedback; we ACK that this may seem like lack of interest to the person giving feedback, thus there is a need to communicate during that process.
WHATWG joint meeting
*group introductions*
Reserved prefix for WAI-Adapt Content Module 1.0
janina: We have developed a spec that is doing something transformative in accessibility.
… AAC (symbols) readers historically have not been able to understand content that uses a symbol set other than the one they know (much like with Braille in the past).
… We've developed a spec that allows content to be expressed in a way that allows the user's chosen symbol set to be used.
janina: We would like to request a prefix for the attributes proposed in this spec.
Lionel: *does a quick demo of Adapt symbols*
<Lionel_Wolberger> https://
<PaulG> This is the link to spoken presentation in HTML https://
<zcorpan> https://
matatk: *Explains the idea of Bliss concept IDs and mapping between symbols* - details in the presentation Lionel shared the URL for above.
annevk: *Explains the requirements as laid out on the working-mode page linked above*
annevk: These include support from implementors (browser vendors); tests; ...
MichaelC: We were planning to go to CR with data-* implementation and then second CR with an agreed attribute/prefix. Is this the right approach, or should we go straight to a chosen attribute?
Neil: What bad thing would happen if this was introduced without a data- prefix.
annevk: If it clashes with another existing idea/project, it could cause confusion.
janina: That's why we started development with data-*
janina: We don't really mind what the prefix is in the end; don't want to clash with other things; would like to replace data- with something more permanent.
annevk: There was a proposal for custom attributes, though it hasn't got far.
<zcorpan> https://
MikeSmith: We have a similar approach with custom elements.
<Lionel_Wolberger> Issue 2271:
<Lionel_Wolberger> note the title of issue 2271, "Make custom attribute rules consistent with custom element name rules #2271"
zcorpan: For standard attributes, we avoid using dashes (unless it's a series of attributes for which we've standardized a prefix).
janina: This is a series of attributes.
zcorpan: If UAs are expected to do something with these attributes; data-* isn't appropriate. The UA should not react to data-* attributes.
Michael: Are you recommending doing our prototyping with our own prefixed attribute?
zcorpan: Yes. It should be a prefix that isn't already widely used.
Lionel: Perhaps 'adapt'
zcorpan: I can query the HTTP archive to find if a prefix has been used before.
<Lionel_Wolberger> Lionel asks Simon to check the HTTP archive for adapt-
matatk: Is there a list of known prefixes?
zcorpan: No, but we can search the archives.
annevk: In theory they should all be in the HTML standard. There are a couple of legacy/SVG attributes that have dashes in them. Generally it's aria-* and data-*
Spoken Presentation
janina: PaulG and Irfan_Ali are working on speech pronunciation that is needed by the educational community.
<PaulG> https://
PaulG: We have a recommendation, and some different ways to implement it.
PaulG: We wanted to bring SSML into HTML as a first-class citizen.
annevk: WHATWG wasn't asked directly.
MichaelC: ACK; we may not have asked directly but IIRC someone, possibly in W3C, suggested it wouldn't be successful.
<PaulG> https://
<PaulG> https://
matatk: Educational publishing and other use cases for controlling pronunciation.
matatk: [rough notes as also scribing] Accessibility for Children CG would like to be able to have more relatable voices for kids.
PaulG: Language is evolving constantly and we need ways to reflect that. Almost all of the things we need are supported by SSML.
Neil: Smart speakers too.
PaulG: In the time since we've been working on this, smart speakers have become popular. SSML can provide better heuristic information to those technologies so that they can make better decisions.
janina: This will make their ML better to.
PaulG: You can ask questions and pose comments on our GitHub repo; please do!
janina: If you can make earlier interventions for kids, for example, this can significantly aid their development.
Fazio: We did some research into this ~10years ago. A large part of why some with cognitive disabilities have outbursts is a lack of being able to express themselves, because their AAC voice is not one they identify with.
… This is a really big education and inclusion issue.
annevk: The examples seem to be more instruction-related rather than voice-related. E.g. 'read this as digits' rather than 'read as voice X'
PaulG: There's a lot of extra metadata that someone familiar with the text would provide.
… It doesn't scale to get actors to voice all content. With this approach with well-curated metadata, the heuristics and ML would be able to fill in the rest.
annevk: So you'd have it reading a children's book like a parent would, with different voices etc.
PaulG: Absolutely.
PaulG: There is room for both more robotic TTS, for high bandwidth (but the pronunciation should be accurate, and regional dialects should be reflected).
Neil: Versailles or Versailles.
PaulG: The city exmample promotes cultural inclusion.
PaulG: Being able to provide someone an IPA translation of your name that every smart speaker/TTS will speak correctly is not possible.
PaulG: @lang doesn't necessarily cover it.
PaulG: Entertainment is important as well (re TTS).
Neil: Sounds like your recommendation is we should fiel an issue?
annevk: Yes. Check the working mode for expected response.
annevk: Some of you have triage permissions on issues. We have telcons on which they are discussed.
MichaelC: We assumed that'd be presumptuous.
annevk: These calls are a good way to reach browser vendors/representatives.
zcorpan: Some of the hints/instructions in SSML seem presentational; makes more sense to have in CSS than markup?
PaulG: There's another document that covers this; gap analysis with different implememntation techniques.
<Irfan_Ali> https://
PaulG: CSS Speech may not be being actively worked on.
zcorpan: HTML has gaps here too; you could replace CSS Speech with something like SSML.
MichaelC: CSS selectors didn't have the granularity that we needed IIRC.
PaulG: These alternatives all have cases they can't make, but SSML covers all of them and has wide support, so could be prototyped very quickly and we'd have it.
annevk: Some of it doesn't strike me as presentational.
zcorpan: I assume SSML audio source approach would fetch an audio file from the server if the user is using AT?
PaulG: If we were to accept the entirety of SSML (which is still up for debate).
zcorpan: This could be a privacy issue.
PaulG: An example would be giving someone directions and including a chime for the trains in the directions. There's no other way to do that in the content, or request the content via the smart speaker, which could be a great use case. There's a need. Could we do without it? Sure.
PaulG: This could be opt-in in future.
Navigation and Interlinear text
janina: EPUB is trying to become more HTML-based over time. There are a couple of things we'd like to get to discuss. One is the previous topic. Another is navigation.
… Previous and Next isn't sufficient. E.g. in a play: navigate by act or scene? Also interlinear publications (e.g. English and French, in sync).
… With historic languages there is a need for interlinear texts.
… Also MusicXML - can we steal from that to build something accessible: e.g. in an Opera, where several are speaking at once, in harmony.
annevk: The navigation algorithm only goes one way.
annevk: Is this browsing around _inside_ a document, moving the focus point etc.?
janina: Yes.
Neil: Screen readers can do this when the tagging is correct.
MichaelC: Let's pass to the EPUB group to articulate.
janina: Possibly this is already available if we use existing HTML to achieve that?
annevk: Yes, but please file issues. Important to file isues that descreibe the matter at hand, which act as a reference point.
Notifications
janina: We're not entirely sure what this issue is; it may've been overcome by events.
annevk: I recall the issue being filed. It was about being overwhelmed by the number of notifications. This is largely out of the hands of the API and more down to the OS to handle.
*Discussion about granularity and interlinear texts.*
janina: e.g. grouping of phrases (bar by bar, or quarter-note by quarter-note)