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

> My suggestion nudges developers gently forward at the AA level by
essentially forbidding non-semantic code,

Maybe I'm missing something here, but requiring every <div> and <span> on
the web to provide semantics, or require that they be contained within an
element which has this semantic context is anything but  "nudging
developers gently". If I understand the proposal correctly, It think it
will require an incredible effort by developers, a huge ask.

I think I'll camp out somewhere near Alastair's proposal.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Tue, Jul 18, 2017 at 5:30 PM, John Foliot <john.foliot@deque.com> wrote:

> 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
>