Re: Subgroups proposal for support personalization and important request from coga

Hi Wayne,

I would say you are partially off, in that one of the goals of ARIA was to
add semantic information to scripted widgets, and that semantic information
is in both the DOM *and* the accessibility tree (which of course is a child
of the DOM) [sic].

I think that the actual problem is that there aren't many tools (outside of
screen readers, and perhaps voice-input tools) that do much of anything
useful with those semantics (or in fact, with any semantics) when it comes
to personalization for COGA or LowViz users.

Off the top of my head, using native and ARIA-furnished semantics, I could
envision a browser extension that did a few "personalization" things. For
example:

   - *HTML 5.1:* Content contained inside of the <aside> element could be
   shown / hidden (on demand) by a browser extension, reducing noise and
   clutter for those who require a simplified interface. Likewise for other
   landmark roles (show/hide the <nav> block, or the <footer> / role="content
   info" block, etc.)

   - *ARIA 1.1:* using aria-activedescendant as a CSS selector, and
   enlarging *ONLY* that <option>'s text in a <select> as you navigate up and
   down the options list (i.e all of the options are at 16pt, except the
   <option> that *is* the active descendant, which could be rendered at 32pt -
   not sure it that would help low vision users, but you get the idea)

Going further:

   - *CSS: *the use of the pseudo-selector of :focus could also do things
   like enlarge the text in the region that has focus, provide 'on-demand'
   contextual assistance for form inputs, etc.


Because of the above, this is why I am suggesting to the COGA TF that we
have 2 SC: one that says that thou MUST use semantics (i.e. non-semantic
divs that lack even a simple labeling mechanism like @title would be
non-conformant), but at AA we do not introduce any other means of applying
those semantics outside of what exists today.

This may not address the need for replacing text with icons (for
navigation), but it starts to leverage semantics for page customization /
personalization by ensuring the conditions are ripe to do so (but, again,
we will need the tools to take advantage of that situation).

Then, at the AAA level we get more stringent, and require that the
'semantics' required be furnished as metadata, including but not limited to
COGA Semantics. "Coga Semantics" is yet another attempt to add more,
abstracted or use-specific semantics to page mark-up, but those semantics
alone don't do much without the other parts of Lisa's proposal (the JSON
<https://github.com/ayelet-seeman/coga.personalisation/tree/JSON-Script>
and scripted bits
<https://github.com/ayelet-seeman/coga.personalisation/tree/Script-Options>).
Here however, the use of metadata will allow for an even finer-grained
control over page elements, as we can build out a larger and more nuanced
taxonomy of values for the various coga-attributes (and / or other metadata
schemas) - but again, *we need the tools*.

Wayne, we can't fix any of this in one week. We can however set the stage
for further forward work towards personalization by asking for and
fostering the right conditions. My suggestion nudges developers gently
forward at the AA level by essentially forbidding non-semantic code, and
also opens the door to further educate developers about the importance of
semantics on a much larger segment of the population (the AAA SC).

But honestly, without tooling, all of this is a theoretical exercise, so we
really need to encourage the "hack for social good" efforts out there to
start building out the tools required to leverage the information being
provided by the semantic markup.

JF

On Tue, Jul 18, 2017 at 3:37 PM, Wayne Dick <wayneedick@gmail.com> wrote:

> To All,
> Yes, we have a gap in HTML and ARIA. How much can we fix in one week.
>
> Is there one item we can isolate that needs semantic that can be added, is
> technology independent (in the 2.1 sense). I am thinking that disambiguate
> div elements is the place.
>
> The problem with ARIA is that people only think of it as contributing to
> the accessibility API, not just providing semantic support. That is what
> personalization requires.
>
> Am I way off?
>
> Wayne
>
> On Tue, Jul 18, 2017 at 1:15 PM, Alastair Campbell <acampbell@nomensa.com>
> wrote:
>
>> Hi Wayne,
>>
>>
>>
>> I think the problem is that (for the context / conventional elements at
>> least) they don’t have native semantics (so not 1.3.1), and elements like
>> links already have a role and a name, value doesn’t match, so they are not
>> covered by role/name/value either.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> -Alastair
>>
>>
>>
>>
>>
>> *From:* Wayne Dickmailto:wayneedick@gmail.com]
>>
>>
>>
>>
>>
>> > What we are proposes really appears to be cases of 1.3.1 that were not
>> covered in previous iterations of the techniques.
>>
>>
>>
>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion