Meeting minutes
pronunciation
<jcraig> group: [mm-hmm sounds re: html-in-canvas proposal for canvas accessibility]
<Lisa> I am also she/her. forgot that bit
Mattatk: We have been talking about pronunciation for a while
… Use cases for education, assessment
… SSML wasn't really viable
… rebooted the TF, keen to explore solutions for smaller groups of problems
… Consulting key things quicker may help adoption
… These are very early documents. For instance, use cases is very short
<Lisa> is there a link?
Mattatk: Focusing on what short of problems people face while using TTS
… People creating educational content, setting exams etc
… Tried different approaches. Industry is trying to solve this problem in its own way via data attributes
… It works similarly to how we proposed at the beginning by specifying bits of SSML in data attributes
… This may not yet be suitable for TR yet but at least it demonstrates that there is a problem
… Do you think there are quick wins in exposing things through the accessibility tree?
<Zakim> matatk, you wanted to discuss agenda
Mattatk: Text style relationships are pretty much covered in terms of roles. I think ATs announce them because it's too noisy to do so
Mattatk: Strong and em are exposed, b and em are not
<Zakim> jcraig, you wanted to ask about the prior non-feasibility... as I recall, the solution was infeasible, but the problem had other solutions beyond SSML
JamesC: Interested in seeing the industry proposal. A simple single attribute for pronuncation was proposed. It was given an i18n alphabet string. The proposal then spun off and then perfect became the enemy of the good. It could go back to an attribute again
JamesC: I'd be open to exploring this as long as it works in moden browsers and engines
JamesN: Interested in use cases outside education
<Zakim> jcraig, you wanted to react to jamesn
JamesC: Tokyo Shoseki, a large book publisher, always has pronunciations strings (SSML, IPA, etc) with any Ruby strings they publish
<Zakim> matatk, you wanted to react to jcraig
Mattatk: Had a call with the Publishing M repaintenance
… Interested in having accessible ebooks
… Based on the different languages, different voices are used which makes it difficult at times to process
Lisa: There are things from education and also from cognitive disabilities
… Stuff you need to jump to could be leveraged for discoverability purposes
… Also keywords and things like that
<jcraig> Lisa:/Lisa:/
Mattatk: Maybe it's different than pronunciation
<Zakim> Jamie, you wanted to flag that I have concerns about specifying precise pronunciation with IPA or similar
Lisa: Being able to have pronuncation of different language as a setting may help
MK: do you have a prioritisation approach?
if you’re not just focusssing on user…
gathering data
MA: good question
currently it’s people turning up with use cases
we’re talking to as many people as we can that have related experiences
we’re trying to get a broad strokes view
then we’ll be look at what are the themes
are any of them general to the point where we should be fixing them
it will get more rigorous as we get further along
<Zakim> jcraig, you wanted to discuss avoiding pronunciation hints solutions avoiding masking technique
JamesC: this is in response to Jamie's comment about mis use of pronunciation to overwrite content
… Preface: No TTS engines don't work this way oday, but something suggested in a ruby breakout yesterday was to compare the string and the pronunciation string before determining if there was a sufficient similarity.
… They should go about reading the text, the ruby, comparing and then do the right thing based on the comparison
… We could, in theory, consider a technique like that to avoid masking. Won't work today or tomorrow, but I don't see a fundamental reason why that couldn't work in the future.
… If the IPA pronunciation is so far off the text we could do this at some point but not today/tomorrow
Lisa: Understanding numerical abstraction is also a problem
… Depending on purpose, numbers may need to be pronounced differently
<matatk> The doc Lisa mentioned: https://
Lisa: There might be different TTS based on each existing use case
… People speaking Hebrew for instance can identify what the word is based on context
… People that are visually impaired have difficulties when it comes to disambiguation, but it is different for people with disabilities. Translation engines often get it wrong disabitlies
… These scnarios may be good for ruby as well
Mattatk: Maybe it could help but we are in ARIA
<Zakim> jcraig, you wanted to react to matatk
JamesC: There is controversy as whether ruby should be used for non-CJK
… I think it'd be reasonable to use it but its value is around what is displayed
Bringing ARIA expertise into HR
JamesN: APA has been successfully providing accessibility reviews
… But there are still issues coming up and it's often too late to resolve them
<jcraig> s/I think it'd be quite reasonable to use it but its value is around what is displayed/I think it'd be quite reasonable to use for other non-CJK scenarios but its value is around what should be displayed, so I think it's inappropriate to use Ruby for pronunciation hints that are NOT meant to be displayed./
JamesN: We think there is expertise in the ARIA WG that can be leveraged to try to catch up issues earlier in the process
Mattatk: Yes please. Doing it earlier is pretty important for some groups
… TAG and APA have been working to expose the idea of earlier accessibility review and also to make the review process more accessible
… Filling in our questionnaire is also of great help
… We prefer by far to have early requests than late ones
… We've done some OpenUI stuff recently
… We talked about giving people user needs and use cases as early as possible, you are the experts for this
… APA may do longitudinal review tracking and we may bring some expertise. When we get a request we get an issue on github and it's assigned to whoever wants to pick it up
… This asynchronous ability is good, there is also calls where this is discussed
… There should be a contact point, and that we'd still like to be us, but we are all open for you to provide input
… We could assign relevant ARIA people when there is an ARIA issue
<Zakim> cyns, you wanted to ask about getting accessibility expertise into incubation discussions (long before working drafts)
Mattatk: Important to present accessibility as a uniform field
Cynthia: Getting accessibility knowledge into incubation is key, sometimes FPWD is already quite late
<jamesn> cd spectranaut_
Cynthia: Some templates could go in the incubation group
spectranaut: Appreciated the Horizontal Review breakout
… I'd like this process fleshed out in a detailed email so that there is a clear path foward
… Some CSS stuff has shipped recently with accessibility problems
… These people may not be familiar with browser accessibility, so we should make sure that there is a safe process within APA to propose feedback
JamesN: Issues are still going to have the accessibility tag, but we still can see them with CSS
<Zakim> Jamie, you wanted to flag that indirect communication can be challenging
JamesT: A single point of contact makes sense, but indirect communication is challenging for complex topics
… Implementation details may involve direct dialog and it's important to foster the ability for direct communications
<jcraig> +1 to Jamie's point that indirect feedback is highly problematic
<Zakim> matatk, you wanted to talk about TAG early design reviews
Mattatk: Agree with what was said. I am also concerned with some of these issues.
… We've also discussed this with some other accessibility experts.
… To Cynthia -- TAG tends to get explainers rather than specs because that's the right time to provide useful review comments
… Intentions are good but they can cause issues somewhere else in the stack
… To JamesT -- People will talk to you because you are the experts but the crucial thing for us is to know about it
JamesC: I stopped during HRs with PF because it was very time consuming and feedback was miscommunicated.
… GitHub helps as it is more efficient to provide feedback within GitHub
<sarah> +1 to what jcraig said
JamesC: I see a lot of benefit for HR process via a project-tracking approach
… This would allow to more easily intercommunicate different people and more easily select who should provide feedback
… Difficult to provide feedback in meetings sometimes, asynchronous ways are better
matatk: Process happens all on GitHub these days
Sarah: Once I know a rlevant thing I can engage on GitHub. We should make it easier to keep track of things we should be providing feedback on
JsmesC: It doesn't have to be a Chair role, just someone with project management abilities
Mattatk: We are going to talk to each other more, so we can discuss the Coga topics later