Whether side by side (as in an opera libretto), or first language line coupled with second language line in many scholarly texts, it is common to provide content in multiple languages. We have not done much to address the resulting accessibility issues that arise. For example the screen reader user would likely need to switch back and forth between both languages segment by segment. Likely the TTS (and braille) in such a user agent will need some kind of reasonable segmentation to keep content synchronized. Likely the less familiar language may need separate settings, almost certainly slower in the more unfamiliar language. On the other hand, designing adequate support is likely to benefit anyone studying a libretto or a scholarly text whether (or not) a disability is involved. Learning foreign languages tends to be difficult for most people, yet so necessary in many academic disciplines. We have a "curb cut" opportunity here together with the accessibility support requirement. APA proposes to discuss the inherent problems and opportunities during TPAC 2023 with Publishing, but also with I18N and WHAT-WG (for HTML implications). What needs normative specification? What's left for user agents--likely not common browsers!## Introduction
Brief introduction to the "use case template".
This template might serve as an approach to document use cases in a more systematic and coherent way.
Recommended format:
As a <Reader | who will benefit from the use case> I would like to <what is the use case> so that <how I will benefit from the use case>
Explanation:
The expressions in angle brackets are meant to be placeholders for the specific content of a use case. The description should be technology-agnostic as it serves to define the users' needs and will not be a guide for a specific implementation.
<Reader | who will benefit from the use case>:
Here you should try to define the role of the user as precisely as possible. For example, instead of "as a publisher" you might say "as a publisher of scientifc textbooks" etc. Please keep in mind that a Reading System could also be a kind of user.
<what is the use case>:
Try to describe your user's need as precisely as possible on a micro-level that could be implemented later on. Instead of a general statement such as "achieve a more user-friendly layout", you should prefer to speak of "achieve a more flexible table layout for huge and complex tables".
<how I will benefit from the use case>:
Describe the ultimate goal of the user's requirement. For example, if you requested "a more flexible table layout for huge and complex tables", you might want to adapt for mobile use - "so that you may consume them on a mobile".
Detail
What is the current problem.
More specific is better to help people understand.
If the use case has a specific audience or circumstance, then who, when and how will people benefit from solving this problem.
Proposal (if any)
A use case does not need to come with a proposal or a recommendation. But if there is any, we can have it documented.
Whether side by side (as in an opera libretto), or first language line coupled with second language line in many scholarly texts, it is common to provide content in multiple languages. We have not done much to address the resulting accessibility issues that arise. For example the screen reader user would likely need to switch back and forth between both languages segment by segment. Likely the TTS (and braille) in such a user agent will need some kind of reasonable segmentation to keep content synchronized. Likely the less familiar language may need separate settings, almost certainly slower in the more unfamiliar language. On the other hand, designing adequate support is likely to benefit anyone studying a libretto or a scholarly text whether (or not) a disability is involved. Learning foreign languages tends to be difficult for most people, yet so necessary in many academic disciplines. We have a "curb cut" opportunity here together with the accessibility support requirement. APA proposes to discuss the inherent problems and opportunities during TPAC 2023 with Publishing, but also with I18N and WHAT-WG (for HTML implications). What needs normative specification? What's left for user agents--likely not common browsers!## Introduction
Brief introduction to the "use case template".
This template might serve as an approach to document use cases in a more systematic and coherent way.
Recommended format:
As a <Reader | who will benefit from the use case> I would like to <what is the use case> so that <how I will benefit from the use case>
Explanation:
The expressions in angle brackets are meant to be placeholders for the specific content of a use case. The description should be technology-agnostic as it serves to define the users' needs and will not be a guide for a specific implementation.
<Reader | who will benefit from the use case>:
Here you should try to define the role of the user as precisely as possible. For example, instead of "as a publisher" you might say "as a publisher of scientifc textbooks" etc. Please keep in mind that a Reading System could also be a kind of user.
<what is the use case>:
Try to describe your user's need as precisely as possible on a micro-level that could be implemented later on. Instead of a general statement such as "achieve a more user-friendly layout", you should prefer to speak of "achieve a more flexible table layout for huge and complex tables".
<how I will benefit from the use case>:
Describe the ultimate goal of the user's requirement. For example, if you requested "a more flexible table layout for huge and complex tables", you might want to adapt for mobile use - "so that you may consume them on a mobile".
Detail
More specific is better to help people understand.
Proposal (if any)
A use case does not need to come with a proposal or a recommendation. But if there is any, we can have it documented.