Re: Response to i18n on Issue 144

I also +1 to Charles and John ideas of using this as a non-normative
advisory.
Happy to read these positive comments:
I am pleased to remind everyone--we drafted this together.

Great teamwork.

- Lionel


Lionel Wolberger
COO, UserWay Inc.
lionel@userway.org
UserWay.org <http://userway.org/>
<https://userway.org>[image: text]


On Tue, Apr 5, 2022 at 6:11 PM Janina Sajka <janina@rednote.net> wrote:

> Thanks, Lionel. I also agree this is just the kind of comment we need on
> issue 144, and I agree that it would provide valuable clarification of
> purpose as informative content in our spec.
>
> Please advise if/when it's added into the spec draft, even
> provisionally. I'm going ahead sometime this week with a chair to chair
> email with
> I18N (yet again) to once again try and unblock this CR blocker.
>
> Best,
>
> Janina
>
>
> John Foliot writes:
> > 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"
>
> --
>
> Janina Sajka
> (she/her/hers)
> https://linkedin.com/in/jsajka
>
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup:       http://a11y.org
>
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Co-Chair, Accessible Platform Architectures     http://www.w3.org/wai/apa
>
>