Re: Proposal for support personlization AA from John, Chris, Jan and myself

Hi All,

David wrote:

   1. Ensure a "conventional name" is used across sites and across the web

   *[JF: I would say that this is essentially correct. At AAA it would be
   from a common taxonomy, but at AA it could be a consistent use of terms
   (taxonomy) across the site. Yes, this is less 'powerful', but still has
   some residual value]*

   2. Ensure these can be programmatically determined to add symbols, and
   streamline content so stuff can be dropped off the page to simplify it.






*[JF: yes, one of the goals, especially at AA is to 'encourage' the use of
   strong semantics at all times. So <div> would be a 'failure', whereas <div
   role="navigation"> would not, thanks to the semantics provided via @role.
   In that case, we potentially *could* use that semantic data for filtering
   or adding icons (for example, a 'smart' plugin could programmatically
   determine that any links inside that <div>, being "navigational links" are
   then in scope for icon-replacement techniques  That alone won't allow for
   the substitution of all text links with icons (for example), however
   consider: <a href="/" title="Return to the Home page"><img src="/"
   alt="ACME Widget Co. logo"></a> *


* where the @title value is an example of providing prose to 'explain' the
   link further.] *
   3. Add context when it is not obvious what the thing is or does. This
   could be prose and/or programmatic. This is a little ambiguous right now.



*[Again, at AAA the fixed or common taxonomy will 'fast-track' this point,
   however in the absence of that fixed taxonomy, it is being suggested that
   prose 'explanatory' or 'advisory' information is provided for a set of
   'conventional controls' (defined*). Additionally, using a fixed metadata
   schema, being the prefered technique, would of course also allow you to
   conform to the AA SC as well (but at AA we don't "demand" it)  As others
   have pointed out, there is some over-lap here between 3.3.2 as well as
   3.3.5, and while the AA suggestions could be accomplished via a tightening
   of 3.3.2 (replace OR with AND), and/or by making 3.3.5 a AA requirement in
   2.1, both of those options are currently 'off the table' per WG convention
   (aka "for now, we aren't touching existing SC").]*


(* Defining the 'conventional controls': I agree with Jason that we have
more work to do here - the List provided is a but starting point.
Personally I think that list is too extensive today, and can stand some
pruning; and yes, issues around internationalization (etc.) will also need
to be addressed. However, at this time the question is: is this headed in
the right direction?)

At the end of the day, I believe what we all *really* would like to see is
that sites would always use a fixed taxonomy of metadata for "controls"
(aka what is currently being proposed at AAA), but we aren't there yet as
an industry (another point reiterated by Jason), and so given that
constraint, what can we ask for (demand legally) at AA in 2.1?


> Otherwise, this version of the proposal runs the risk of requiring
authors to add metadata that will never, in fact, solve anybody’s
accessibility issues.

I think I'll push back on that sweeping statement just a bit Jason.

Obviously a fixed taxonomy of metadata values is significantly more useful,
however we have long-standing examples of "open" metadata values (*<meta
name="description" content="Awesome Description Here">*) that do afford
some value, and for some users that may be sufficient.

JF

On Fri, Jul 21, 2017 at 8:04 AM, White, Jason J <jjwhite@ets.org> wrote:

>
>
>
>
> *From:* Alastair Campbell [mailto:acampbell@nomensa.com]
> *Sent:* Thursday, July 20, 2017 6:08 PM
>
> “Purpose of controls: In content implemented using mark-up languages, the *conventional
> name* of *common controls* can be programmatically determined.”
>
>
>
> Definitions:
>
>    - Common controls is essentially Lisa’s list.
>    - Conventional name, a name for the common control available in a
>    public vocabulary (or taxonomy if you prefer).
>
>
>
> I’m not wedded to the term “conventional name”, but I think the concept
> has legs.
>
> *[Jason] I think it does, too. This is a clearer statement of what I
> originally thought the proposal advanced earlier this week was intended to
> achieve.*
>
> Would the “conventional name” be a localized string? “Accessible name”
> certainly is, but it’s intended ultimately for human consumption, whereas
> “conventional name” (if I understand your proposal correctly) is not – or,
> at least, it’s meant to be both human readable and unambiguously
> identifiable in software. I think you would have to place constraints on
> the public vocabulary (e.g., used by AT to enhance accessibility).
> Otherwise, this version of the proposal runs the risk of requiring authors
> to add metadata that will never, in fact, solve anybody’s accessibility
> issues.
>
> ------------------------------
>
> This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
>
> Thank you for your compliance.
> ------------------------------
>



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

Advancing the mission of digital accessibility and inclusion