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

I think it is important to point out here that ePUB also has a fixed Accessibility taxonomy…..

 

…another reason we need to be sure to be working also with the new W3C ePub/dPub community in general and the dPub Accessibility Task Force specifically. 

 

​​​​​* katie *

 

Katie Haritos-Shea 
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)

 

Cell: 703-371-5545 |  <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA |  <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545 |  <https://twitter.com/Ryladog> @ryladog

NOTE: The content of this email should be construed to always be an expression of my own personal independent opinion, unless I identify that I am speaking on behalf of Knowbility, as their AC Rep at the W3C - and - that my personal email never expresses the opinion of my employer, Deque Systems.

 

From: John Foliot [mailto:john.foliot@deque.com] 
Sent: Friday, July 21, 2017 10:27 AM
To: White, Jason J <jjwhite@ets.org>
Cc: Alastair Campbell <acampbell@nomensa.com>; lisa.seeman <lisa.seeman@zoho.com>; public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>; W3c-Wai-Gl-Request@W3. Org <w3c-wai-gl@w3.org>
Subject: 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 <mailto:jjwhite@ets.org> > wrote:

 

 

From: Alastair Campbell [mailto:acampbell@nomensa.com <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.

 <mailto:john.foliot@deque.com> john.foliot@deque.com

 

Advancing the mission of digital accessibility and inclusion