Re: Response to i18n on Issue 144

Nicely done Lionel, and a Huge +1 to Charles. In particular I believe this
could and *should* be included as authoring advice in our spec:

AAC is most used on short texts, procedural texts or instructions. For
lengthier discursive or narrative texts, AAC users nearly universally turn
to audio and video. No AAC expert that we consulted with knew of an AAC
user that would want AAC on every word of a story, article or web page:
when they have a lot to read, they have it read to them by an assistive
technology or turn to an audio or video alternative source.


I'd suggest providing this advice as non-normative advisory, but in the
body of the spec (associated to the symbols attribute). I could envision it
looking something similar to the Notes found in WCAG 2.1 (i.e. in a green
bounding box, labeled as NOTE:)

Additionally, the text could likely do with a minor edit to make it more
declarative and less 'informative' - perhaps something like:

----------
NOTE:
Authors should reserve ACC conversion to short blocks of texts, procedural
texts (lists), or instructions.  From an authoring perspective, AAC users
do not expect AAC conversion on every word of a story, article or web page:
when they have a lot to read, they have it read to them by an assistive
technology or turn to an audio or video alternative source.
----------

JF

On Tue, Apr 5, 2022 at 9:15 AM Charles LaPierre <charlesl@benetech.org>
wrote:

> Very well written and thought out.
>
> I think some of this highlighted below should also go into our
> specification in the Symbols section to help with the understanding on how
> Symbols are used.
>
> Thanks
> Charles
> EOM
>
> Charles LaPierre
> Principal, Accessibility Standards, and Technical Lead, Global Certified
> Accessible
> Benetech
> Twitter: @CLaPierreA11Y
>
>
>
> On Apr 5, 2022, at 1:40 AM, Lionel Wolberger <lionel@userway.org> wrote:
>
> Sharing to the list for convenience: you may see the full thread at
> https://github.com/w3c/personalization-semantics/issues/144
>
> Thanks to Janina and everyone on last call for helping draft this.
>
>
> Personalization TF and APA-WG thank you for this response, and the details
> of SVO and VSO which we were not aware of. However, as you will see below,
> this concern does not seem critical. AAC is used for procedural texts, and
> the markup shared above--not the rendering, the markup--shows symbol order
> is preserved under LTR or RTL.
>
> To be clear, I quote r12a and respond issue by issue:
>
> [r12a wrote] *Thank you for the recipe example. Unfortunately, we still
> struggled a little.... A sentence or two that show how such different
> syntaxes would be handled would be useful.*
>
> [TF Response] There is a critically important reason why we marked up a
> recipe and not a sentence. We did this on advice received from multiple AAC
> experts, as follows: AAC is most used on short texts, procedural texts or
> instructions. For lengthier discursive or narrative texts, AAC users nearly
> universally turn to audio and video. No AAC expert that we consulted with
> knew of an AAC user that would want AAC on every word of a story, article
> or web page: when they have a lot to read, they have it read to them by an
> assistive technology or turn to an audio or video alternative source.
>
> [r12a wrote] *We see that the images in... do show different orders for
> the images in the English and Arabic..... We were looking for confirmation
> of whether that matches your expectation....*
>
> [TF Response] The Content Module specification stipulates markup, not
> rendering. Rendering is at the discretion of the user-agent or other
> technologies downstream and is not in scope of the specification. Matatk
> shared a possible rendering, and r12a's comment addresses this -- but all
> of this was provided only as a convenience and is out of scope of the
> specification. The HTML markup associates a symbol to one or more words, at
> the discretion of the page's author. This association of symbol to text is
> unaffected by LTR or RTL of the marked up content.
>
> [r12a wrote] *Here we were also disadvantaged because we don't read
> Hebrew and couldn't even copy the text into a translator...*
>
> [TF Response] We sympathize! It was not easy for our TF to scrounge up
> AAC experts fluent in RTL languages as well as native speakers for an
> accurate translation. We did just that, at no small effort, to share the
> representative sample above, the HTML marked up recipe. We repeat that this
> HTML sample is available to i18n since beginning of December 2021.
> We conclude with the conclusion above: Notice how symbol order is
> preserved: the IDs appear in the same sequence, but this time they are
> associated with words that will render RTL.
>
>
> Lionel Wolberger
> COO, UserWay Inc.
> lionel@userway.org
> UserWay.org <http://userway.org/>
> <https://userway.org/>[image: text]
>
>
>

-- 
*John Foliot* |
Senior Industry Specialist, Digital Accessibility |
W3C Accessibility Standards Contributor |

"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"