W3C

- DRAFT -

Spoken Pronunciation Task Force Teleconference

29 Jul 2020

Attendees

Present
Irfan, Dee, paul_grenier, Jamie, janina, Joanmarie_Diggs, SteveNoble_, becky, Roy, George, NeilS
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Dee

Contents


<Irfan> scribe: Dee

<NeilS> Neil+

Agenda Review & Announcements

technical approach

Janina: Looking for the most generic solution to pronunciation in a way that works and be attractive to the mainstream.
... We need to decide on a technical direction.

Mark: Overview of pros and cons
... Educational content needs to be pronounced correctly. There are many attempts. Some have misused of ARIA. Some use attributes. Need a solution for screen reader technology as well as read aloud tools. We are now at a fork in the road. We have seen some traction for the attribute model. We have also explored inline SSML.
... Both the attribute and SSML models have advantages and disadvantages.

Paul: The MathML and SVG implementations provided at path to follow. For example SVG has a reuse feature.
... Switching to JSON parsing could be challenging.

Mark: We have looked at the authoring concerns for JSON and the authoring tool would do the encoding.

Peter: For authoring SSML, TextHelp has completed an authoring UI. It is working just fine for two different vendors.

Mark: JSON structure can map to other proprietary or non-proprietary markup.

Jamie: Not sure JSON is more portable than SSML.

Glen: JSON is easier for a screen reader.

Janina: If there is strong support for SSML, we believe that it could be treated like SVG.

Ease of exposure is key.

Whether it is JSON or not.

Mark: One of the other approaches is to have attributes, SSML function attribute followed by options. The disadvantage is that the DOM would need to be accessed many times.

Joanie: At this point, on the same page as Glen. Object attribute on the associated element.

Glen: Being able to get an entire chunk of SSML at once would be preferable.

We need to not conflate things.

Janina: We need to construct a bridge.

George: In Japan, the pub industry is in need. Not certain that it is AT that will process the info for read aloud.

Paul: Non-AT applications would have the same access they have currently to the DOM or use a Web API.
... no lack of access happening. Do need to separate Braille from AT annoucement.

Jamie: Browser perspective, exposing inline SSML via a mechanism is not difficult. Using JSON doesn't fit the web.

Paul: benefit to pub industry is the attribute can be used immediately

Janina: prototyping mechanism is data dash, for validation

Mark: The SSML is really presentational, defining how text will be presented by a speech synthesizer.
... Wondering about the author burden when pronunciation cues are needed on scattered throughout the document.

George: Many pubs using XML and then transform it. Validation is important.
... Epub check is a validator.

Geroge: would like to future-proof, aligning with the web is essential

Irfan: On the browser side, we need to do some work for both approaches.
... How can we proceed further?

Janina: AT doesn't seem to have a preference. The attribute is something we can do sooner.

Joanie: Agrees

Jamie: Doesn't it mean that work has to be done in browsers?
... work needs to be done regardless of the choice that is made

<mhakkinen> Background: data-ssml was a placeholder that could allow prototyping now. We originally thought about aria-ssml.

Peter: using data dash

Mark: data dash allowed us to prototype, not intended as a final solution

Janina: discuss with web incubator community group

Jamie: has contacts, concern is the validation, not my territory

Janina: had connections for DOM validation concern

Jamie: understand desire to move fast and use attribute, but if we want it to work more widely, inline SSML seems cleaner and more web-like

Janina: goal is to get more content to pronounce correctly

Mark: challenges for student experiences for assessments

Jamie will try to help pull together conversations.

Mark: Include read aloud community in conversation.

Agreement to set up one more round of this discussion to include others.

Jamie: strong inclination toward inline SSML

Irfan: survey was sent, most were inclined to an attribute model

Jamie: does using the attribute model solve the presentation concern?

Paul: PLS gets close to a separaton.

<George> George needs to depart. Bye

Mark: Gap analysis document looked at potential ways. SSML seems to solve more of the challenges.

trackbot, end meeting

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/07/29 15:04:01 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: Irfan, Dee, paul_grenier, Jamie, janina, Joanmarie_Diggs, SteveNoble_, becky, Roy, George, NeilS
Present: Irfan Dee paul_grenier Jamie janina Joanmarie_Diggs SteveNoble_ becky Roy George NeilS
Found Scribe: Dee
Inferring ScribeNick: Dee

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 29 Jul 2020
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]