- From: John Foliot <john.foliot@deque.com>
- Date: Mon, 9 Apr 2018 20:24:57 -0400
- To: Joanmarie Diggs <jdiggs@igalia.com>
- Cc: "lisa.seeman" <lisa.seeman@zoho.com>, public-personalization-tf <public-personalization-tf@w3.org>, "group-aria-chairs@w3.org" <group-aria-chairs@w3.org>, Janina Sajka <janina@rednote.net>
- Message-ID: <CAKdCpxz07Efcv55+OywaTR-xbdHYPWWTsmaC-Dzfd9HA75M0LQ@mail.gmail.com>
I'd also just like to add that moving Personalisation from under the ARIA WG to under the APA WG will have zero practical impact on the work being done by the Task Force. It is in many ways organizational, and in the process opens the TF to potential techniques and technologies not directly impacted by, or required to conform to ARIA notation or methodologies (not all AT requires ARIA to function properly). I see that as a positive outcome of the move. Additionally, as Joanie notes, if we need "something" from the ARIA WG, they are committed to addressing that need in the future. This matches the current commitment today, so we lose nothing in the move. JF On Mon, Apr 9, 2018 at 11:12 AM, Joanmarie Diggs <jdiggs@igalia.com> wrote: > Hey Lisa. > > What you describe below means that Personalization Semantics would be > using ARIA. And building upon ARIA strikes me as a possible way forward. > I can imagine an extension which looks for the personalization semantics > and modifies the authored content at load time to inject ARIA so that, > using your example, an element with aui-action has "role='button'" added > to it. Then ATs would see the element with the action and believe it was > a button. To be clear: It would still up to the author to make it work > like a button, just like it is with all of the ARIA roles: ARIA itself > doesn't add button functionality and the ATs don't do that > implementation work either. > > Getting back to the discussion at hand, the ARIA Working Group has > already committed to adding roles, states, and properties so that > technologies which require and/or build upon ARIA have what they need to > accomplish that. For instance, AOM needs reflection and Web Components > needs role parity with HTML so we've agreed to address those needs > within ARIA. If, as you continue to develop Personalization Semantics, > you find that implementability is completely blocked until something is > added to ARIA please let us know. > > --joanie > > On 04/09/2018 10:40 AM, lisa.seeman wrote: > > 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 <http://il.linkedin.com/in/lisaseeman/>, Twitter > > <https://twitter.com/SeemanLisa> > > > > > > > > > > ---- 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 <http://il.linkedin.com/in/lisaseeman/>, Twitter > > <https://twitter.com/SeemanLisa> > > > > > > > > > > ---- On Sun, 08 Apr 2018 20:21:08 +0300 *Joanmarie > > Diggs<jdiggs@igalia.com <mailto: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 > > > > > > > > > > > > > > > > > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion
Received on Tuesday, 10 April 2018 00:25:23 UTC