Re: Possibility of moving Personalization Semantics out of ARIA and into APA

Hi Lisa.

Responses inline.

On 04/08/2018 06:50 AM, lisa.seeman wrote:

> I am not sure what the methodology in deciding these criteria and
> definitions. They were  not the original intention of ARIA. (I wrote
> the first drafts.) Originally ARIA was to add semantics needed for
> accessibility that were missing. To solve the problems and roadblocks
> for inclusion.

[...]

The methodology is descriptive of how ARIA is implemented. Adding
semantics needed for accessibility that were missing is a huge area.
There is not necessarily a one-size-fits-all solution. Which brings me
to the following:

> 1. ARIA does not control what content will be loaded - this is true
> also for personlization semantics

>From your list of items described in your Explainer, there are:

* Language they understand
* Less features

In my mind, the most straightforward way of ensuring users have content
in a language they understand is for the author to provide multiple
versions of the same content, including alternatives for users who need
number-free content, concrete/non-figurative language, a particular
reading level, etc. Having done so, a tool which knows the user's
personal needs regarding language would examine all of the versions
provided by the author and display only the content suitable for that user.

Similarly, if too many features make content difficult for someone to
process, an author could identify the importance level of each feature
or area of content. Having done so, a tool would examine each item's
importance level and include only the ones that meet the criteria
identified by the user.

In both cases, what content is loaded and displayed for the user and
what content is not displayed is directly impacted by the
personalization needs of the user.

> 2. ARIA does not impact how loaded content will be displayed. - this
> is not always true. It effects the UI, and  can impact what is shown
> and hidden when things will be read and the tab order etc.  In a
> similar way to personlization semantics.

What is displayed by the web browser doesn't change as a result of ARIA.
Taking your example of hidden: If you put aria-hidden="true" on an
element, that doesn't cause the element to not be displayed, nor does it
exclude it from the DOM; it only excludes it from the accessibility tree
so that screen readers don't know it's there and won't speak or braille
it. Similarly, if an author applies aria-hidden="false" to content which
is hidden via CSS, that CSS-hidden content won't be displayed by the
browser; but that content will be included in the accessibility tree so
that screen readers will present it in speech and/or braille even though
it's not displayed by the browser. As for tab order, what in ARIA
changes that? The tab order is what gets focus next when the user
presses the Tab key. ARIA doesn't override that.

> 3. ARIA information is conveyed via accessibility APIs. Again I am not
> sure this is not always true. Sometimes we are leaders and the APIs
> move to meet us. in this case we are enabling new generation of
> accessibility support and it may well be in the future that
> accessibility apis map to what we are doing. I am not sure this works
> with epub module etc.

I implemented support for the DPub-ARIA roles for Linux, macOS, and
Windows (IAccessible2) in Firefox. I also implemented support for
DPub-ARIA roles in WebKitGtk (and fixed some issues in the Safari
implementation). I then implemented support for those roles in the Orca
screen reader. While I cannot tell you about any other ways the
publishing industry might be utilizing DPub-ARIA (e.g. through
publishing-specific tools), I can tell you that DPub-ARIA's
implementation in the user agents and assistive technologies was
necessary to make those roles accessible. So if that's what you are
referring to when you say the "epub module," then I would beg to differ
with your assertion: DPub-ARIA was implemented just like the rest of ARIA.

With my implementor hat on, I don't believe user agent implementations
of personalization semantics would be done in the same fashion as ARIA.
And I stand by my assertions that ARIA does not impact what is displayed
on screen and that exposure via accessibility APIs is a necessary aspect
of an ARIA implementation. In contrast, I don't see how some of the
crucial aspects of personalization semantics can be implemented without
impacting what is displayed on screen, and do believe much of what you
need to accomplish can be done without any
personalization-semantics-specific accessibility API exposure.

Given that the nature of ARIA and the programmatic implementation of
ARIA each seem strikingly different from personalization semantics, I
see no benefit in constraining personalization semantics to ARIA. Nor do
I see any benefit in expanding ARIA to be so broad as to incorporate all
accessibility needs involving additional semantics.

--joanie

Received on Sunday, 8 April 2018 17:21:50 UTC