- From: Alastair Campbell <acampbell@nomensa.com>
- Date: Fri, 21 Jul 2017 14:58:53 +0000
- To: John Foliot <john.foliot@deque.com>, "White, Jason J" <jjwhite@ets.org>
- CC: 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>
- Message-ID: <03498717-3B95-46BF-BADB-17279989D902@nomensa.com>
I’ll chip in inline, sorry for the length: 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] [AC: I disagree, unless you’re putting on the user the task of loading multiple taxonomies it isn’t just less powerful: it doesn’t do anything.] 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.] [AC: I think that’s a separate point, that’s part of 3. Adding symbols requires very specific semantics, it isn’t available with the current semantics.] 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*). [AC: How does providing *different* explanations for the *same* controls across sites help anyone? I agree it is helpful for some controls, but it is least helpful (or just unhelpful) for common ones!] JF: 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) [AC: That’s the same principle David and I are suggesting, just from a different approach.] JF: (* 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; … JF: 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 [AC: I have to push on that, we have a list of 75 things that could be pruned and edited over the next few months, how are we not ready? It is of far less scope and more feasible that some of the current and proposed SCs.] JF: 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. [AC: And these are not conflicting requirements, I’d like to use a closed vocabulary for the AA requirement, and the open approach more broadly at AAA.] Cheers, -Alastair
Received on Friday, 21 July 2017 14:59:23 UTC