Math read aloud fundamental experience

There are many requirements associated with the read aloud experience with math. Clearly reading at a slower speed than prose is one requirement. However, there are many other considerations and it would be good to identify the most important features. Another consideration is the level of difficulty in the implementation of the feature.

# Math Read-Aloud Requirements
## Must
• Math must be read as meaningful spoken content rather than skipped, misread, or exposed as raw markup.
• Math must be integrated into the normal read-aloud flow rather than requiring a separate interaction mode.
• The system must maintain clear visual synchronization when reading math, at minimum by highlighting the full expression being spoken.
• Users must be able to configure key behaviour where preferences materially affect comprehension, especially how math is signalled and how it is spoken.
## Should
• Math reading speed should be adjustable relative to prose reading speed.
• The experience should provide a clear but non-disruptive way to signal when math begins, with signalling options left to user preference.
• The system should support replay or repeat of recently spoken math to help comprehension without requiring full interactive exploration.
• Implementations should aim for consistent behaviour across reading surfaces by following a shared baseline framework.
## Could
• Systems could highlight individual components within an expression as speech progresses.
• Systems could offer additional personalization such as verbosity controls for math speech.
• Systems could provide enhanced rewind or scrubbing features for math segments.
## Open questions to resolve
• How much automatic behaviour should be built in versus left to user settings?
• How should inline math and block math differ, if at all?
• How will the needs of different languages be accommodated?
• Which categories of mathematical notation must be supported in scope?
• What user controls are essential for math speech, for example speed, style, and verbosity?
• Should different math speaking styles be supported for different user needs or educational levels?
• What level of synchronized highlighting is needed for comprehension: whole expression, sub-expression, or token-level?
• What fallback behaviour is required for unsupported or invalid math markup?
• How much replay, rewind, or navigation support is needed before read-aloud becomes genuinely usable for math?

No file, test, or code entry point is named. Start by reviewing the Must, Should, and Could requirements alongside the open questions, then identify the supported math notation, controls, synchronization level, and fallback behavior that need decisions. Done means the requirements and implementation scope are resolved into an agreed baseline.

Written by the indexing model from the issue text.