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

The main issue is that I think this should be integrated and mapped to ARIA. For example, aui-action should be types of role=button. The new list of roles should be types of different  landmarks roles. It might not be stage 1, because it will take a while for the AT's to adopt all the terms but it is how it should be done.


All the best

Lisa Seeman

LinkedIn, Twitter





---- On Mon, 09 Apr 2018 10:07:44 +0300 <lisa.seeman@zoho.com> wrote ---- 

There is a section on roles that is completely part of ARIA as implemented now. For the first ten years of ARIA we never limited ourselves by these criteria. It seems to me they are created to exclude us. 

All the best

Lisa Seeman

LinkedIn, Twitter





---- On Sun, 08 Apr 2018 20:21:08 +0300 Joanmarie Diggs<jdiggs@igalia.com> wrote ---- 

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