Re: Response to i18n on Issue 144

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

Received on Tuesday, 5 April 2022 15:12:18 UTC