Feedback - Internal development team at RNIB

[TOraTErF]

Hi there,

Not sure what the correct procedure is for this, so I'm just going to add a list of points raised from internal discussions with RNIB developers:

• Attributes within HTML is a fine solution, though we believe it would potentially be more powerful, and better-suited to a CSS implementation as we believe it is more presentational than semantic
• The ‘data-‘ attribute prefix is typically used in a way that is scoped to an application, its use here feels incongruous with the rest of the HTML attributes; we believe it would make more sense as a first-class attribute
• The attribute approach is likely to lead to additional markup bloat, which may make maintainability and comprehensibility more difficult
• The JSON-based solution would be served by having an enforced schema
• The behaviour regarding missing attributes / malformed attribute values / incorrect JSON should be formalised as part of the specification; leaving such a decision to browser vendors is likely to lead to confusion among users and developers
  • It is our belief that in the event of incorrect input, the implementation should treat the element as if it did not have the behaviour applied, allowing the browser and assistive technology to fall-back to defaults

Thanks,

Dean

[AutoSponge]

Dean,

Thank you for your considerate feedback.

The task force evaluated the CSS Speech specification for a possible solution to our use cases. You can find the results of our research in the Gap Analysis document: https://w3c.github.io/pronunciation/gap-analysis_and_use-case.

The data-* is specified by HTML for prototype implementations. We will eventually get our own attribute(s) once we coordinate with HTML standards groups.

We agree that a JSON schema would help implementors validate their work. However, browsers or AT may choose an event-base parsing approach which can not benefit from a schema. It will be their decision.

Errors triggered by malformed instructions will most likely go ignored, the way invalid HTML is currently treated. Once again, we feel this aligns with HTML specifications. Although we encourage authoring tools to provide this feature, it goes beyond the realm of our specification at this time.