Re: Rolling the personalization SC into 4.1.2

+1 to this Alastair

 Then on the other side of August we could decide whether to "role" it into
4.1.2 (excuse the pun)

I also think dropping first bullet wise... stick to COGA metadata.

So then we can publish the meta data requirement in next draft "at risk"
and hope the infrastructure comes together before publishing. If it's there
by canditate recommendation then publish it, otherwise pull it for future
version .

I think everyone wants to see this approach succeed, and if we can
demonstrate it in a meaningful and implementable way it will be accepted....

We may need to narrow it a bit tighter in terms of which subset to require,
where the semantic elements are not yet  ready for other languages. For
instance, do all cultures have a first name and family name?

But we can work that out after August.

On Fri, Jul 14, 2017 at 4:38 AM Alastair Campbell <acampbell@nomensa.com>
wrote:

> Sorry for the long email, the summary is:
>
>
>
> The current personalisation SC is actually quite narrow in scope, and
> appears to be fairly easy to implement and test (please see the details
> below).
>
> I think it would be better to focus on the meta-data aspect (following a
> 4.1.2 approach), but the main hole is whether there is any technology to
> use the meta-data in the next couple of years.
>
>
>
>
>
> David wrote:
>
> > I thought pertinent to that conversation is the early COGA proposal to
> modify 4.1.2, which was done in conjunction with Rich Schwerdtfeger.
> https://github.com/w3c/wcag21/issues/22
>
>
>
> I also made the argument to put under/with 4.1.2, Lisa pointed out it
> would need to be re-written to work for the COGA use-case. I think it got
> pushed aside due to the “no editing current SCs” in this part of the 2.1
> process.
>
>
>
> Personally I would prefer to take a 4.1.2 style approach, such as:
>
> “*Contextual information: Where a defined vocabulary is available,
> contextual information can be programmatically determined for sections and
> controls*.” [1]
>
>
>
> (NB: I think this could also be used to say that ARIA landmarks are
> required without re-scoping current SCs.)
>
>
>
> However, if we take the current route of having a mechanism OR meta-data,
> the current proposal is quite constrained and testable. From the call
> yesterday I think there are some mis-understandings about the current
> proposal.
>
>
>
> I would suggest a re-wording to simplify it, such as:
>
> “*Common navigation elements, common form elements and common interactive
> controls can be personalised by:*
>
> *- a mechanism that enables the user to add symbols OR*
>
> *- contextual information that can be programmatically determined.*”
>
>
>
> There are three lists of things (included in the definitions) which map to
> the pre-defined (testable, ARIA style) coga-personalisation spec:
>
>
>
> *Form elements*: name (corresponds to both first and family), first name,
> family name, initial, phone (corresponds to a user phone number), cell
> phone, address 1, city, state… [2]
>
> *Interactive controls*: compose, delete, next, previous, submit, undo,
> cancel, buy, add label, move, view, save, send… [3]
>
> *Navigation elements:* home, contact us, our phone, our email, site map,
> help, about us… [4]
>
>
>
> This is basically ARIA landmarks ++.
>
>
>
> There is some argument discussion to be had on the details of those, but
> it is clear to me how to implement. I would not want to add the work of
> creating a personalisation mechanism so I would add meta-data like so:
>
>
>
> <a href=”/” coga-destination=”home”>Home</a>
>
>
>
> (Or “pref-destination” was acceptable to Rich Schwerdtfeger as something
> not limited to one user group.)
>
>
>
> Then the user could have a browser/extension that shows icons on mouseover
> like this demo:
>
> https://www.widgit.com/support/insite/index.htm (which works on all text,
> but I’m assuming it would be only items with personalisation meta-data in
> this context.)
>
>
>
> I don’t see the argument that the title attribute is a loophole, as the
> same argument applies to 4.1.2. That uses “programmatically determined”,
> and does NOT specify a vocabulary. It relies on the definitions of ‘name’
> and ‘role’, but it is the bazillion sufficient techniques that enforce ARIA
> as the spec to use.
>
>
>
> This proposal defines ‘contextual’, and we can discuss the details of
> that, but it is the same principle as 4.1.2.
>
>
>
> This SC has been refined and refined, and I think is quite reasonable from
> a testability and website implementation point of view now.
>
>
>
> The one remaining objection (for me anyway) is whether there is user-side
> technology to do something with the meta-data.
>
> I appreciate the chicken & egg situation we’re in, on the low vision side
> we have a similar problem but there are at least two projects working on
> browser extensions that do what we need, plus scripts we can use for
> testing.
>
>
>
> Lisa: Are there any projects underway to make use of this? Otherwise we’re
> in a situation of saying to people: implement this, but no one can use it
> yet.
>
>
>
> I also agree with Chris’ point that if we specify that creating a
> mechanism is a good way to pass this, then all manner of terrible
> implementations will be created and it will probably do more harm than good.
>
>
>
> Lisa, I think the motivation for the first bullet was so that things like
> PDFs could have alternative content versions, but given the narrower scope
> of the current SC, is that still a concern? (PDFs with navigation & forms
> are generally a disaster anyway?!)
>
>
>
> I suggest (again focusing on the meta-data aspect, either with the one I
> proposed above, or something like:
>
> “For c*ommon navigation elements, common form elements and common
> interactive controls contextual information can be programmatically
> determined.”*
>
>
>
> Cheers,
>
>
>
> -Alastair
>
>
>
> 1] https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/0005.html
>
> 2]
> https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-6/guidelines/terms/21/common-form-elements.html
>
> 3]
> https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-6/guidelines/terms/21/common-interactive-controls.html
>
> 4]
> https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-6/guidelines/terms/21/common-navigation-elements.html
>
-- 

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>