Re: explaining my issue with one single attribute, and review of the three options.

Hi Lisa,

While I am trying to understand your concern, I'm also struggling to see
how this is confusing. You proposed the following:

<p aui= " simplification:critical symbol:(
https://blissorsomething.com/uri.html)"    easylang="This is a long easy to
understand description, it could have 3 sentences. People are likely to
have bugs by adding quotes."   numberfree = "this is a a description which
avoids number. it could have four sentences and again people may add quotes
or brackets that would add bugs." > some text  about this example </p>

Candidly, I fail to see how that is materially different than this:

<p aui="simplification:critical; symbol:url(
https://blissorsomething.com/uri.html); easylang:("This is a long easy to
understand description, it could have 3 sentences. People are likely to
have bugs by adding quotes."); numberfree:("This is a a description which
avoids number. It could have four sentences and again people may add quotes
or brackets that would add bugs.")" > some text  about this example </p>

In your example, you are using spaces to denote three different
"attributes", while in my example, each aspect of the paragraph is
separated by semi-colons, in a fashion *EXACTLY LIKE CSS NOTATION* - in
other words, a familiar pattern that most hand-authored contributors will
recognize and pick up (I assert) quite easily.

Additionally, I am proposing colons while you are proposing equals symbol,
which frankly seems to be nothing more than personal preference (with the
exception that colons and semi-colons - as I propose -  are used for
compound attribute values already: *<p style="color:red; font-weight: bold;
font-family:"MS Comic Sans", sans-serif;">* - a pattern that authors have
been using for almost two decades now).

Lisa, when you asked "Can I (we) spot the bugs?" my answer is "Absolutely!
You aren't using semi-colons to separate concepts, and the lack of
quotation marks makes it harder to parse what is prose text, and what is
"code"". I don't think either of these are showstoppers, and once we get
the pattern confirmed and "locked-in" I don't see why a linting tool or
other validator couldn't also pick up these mistakes. And given that the
authoring pattern is identical to CSS in structure, there is absolutely no
reason why you could not also author the following to make it clearer for
human parsing:

<p aui="simplification:critical;
             symbol:url(https://blissorsomething.com/uri.html);
             easylang:("This is a long easy to understand description, it
could have 3 sentences. People are likely to have bugs by adding quotes.");
             numberfree:("This is a a description which avoids number. It
could have four sentences and again people may add quotes or brackets that
would add bugs.")" > some text  about this example </p>

...because of course browsers ignore extra white space. Additionally, the
addition of quotation marks *may or may-not* be a problem, as currently
there are NO PARSING RULES for either of the proposed patterns (so I assert
your concern may be premature). If we look to inline CSS as a "hint",
either of these are valid today:

style="*font-family:"MS Comic Sans", sans-serif;"*

or

style="*font-family:MS Comic Sans, sans-serif;"*


(in other words, the quotation marks are optional - so we can certainly
look to adopt that 'rule' as well. As Google's Alex Russell famously said,
"This is code, we can do whatever we want")

In my mind, what this is coming down to is the choice between using =
(equals symbol) versus : (colon) to separate term from value (i.e., *term:
value*, versus *term="value"*), and your desire to see multiple attributes
versus my concern that we've already got far too many "accessibility
attributes" thanks to the ever growing taxonomy of ARIA attributes (48 and
counting).

As you may recall, back during the Sapporo TPAC (2015), a number of
accessibility folks were concerned then about the "ARIA all the things"
proposal that was coming forward, when the very first draft of the
COGA-attributes (back then, just more ARIA-attributes) was proposed.
Representatives from many larger-scale organizations vocally object to that
approach (which then saw us go from more ARIA-attributes to COGA-*
attributes, and then to AUI-* attributes). The fundamental problem however
remains: too many attributes, irrespective of their prefix. At this point,
you are now asking for 3 new attributes (without prefixes), which we may
also find a difficult ask to justify to Web Platforms WG (and WHAT WG as
well - sadly).

In your other email, you spoke of experience and implementations. Lisa,
while I respect your years of dedication to the cause, I too have been
creating and teaching about accessible web sites for close to two decades,
in both "small shop" scenarios as well as at a major education institution
(Stanford University), one of the world's largest banks (JP Morgan Chase),
and via Deque consulting with multiple Fortune 500 companies, and so I have
what I believe to be justifiable concerns about scaling. And while I agree
that in the early days, the application of personalization markup to the
code base will come from dedicated, hand-coding authors, if we desire to
see this grow beyond that to a more mainstream adoption, we MUST
be cognisant of how this will be taken up at scale. That may not be a
concern you share at this time, but as the AC Rep for Deque, it is a
concern that my employer will likely have as we move forward.

JF


On Tue, Sep 25, 2018 at 8:50 AM lisa.seeman <lisa.seeman@zoho.com> wrote:

> Hi Folks
>
> I wanted to explain my example from last night.
>
> I strongly do not believe we can rely on large authoring tools to
> automatically generate the web code for authers to get it right. some of
> our user cases are about small user groups (such as symbol) who desperately
> need any content they can use. The content being made for them may be small
> sites making content specifically for these users. Therefor we have to
> allow authers who are less experienced to manage this.
> Also the only way to test for bugs is via running an extension against
> different profiles and seeing if it works as expected. in other words, bugs
> will often not be found. Therefor avoiding author errors is critical for
> this be be of use.
>
> The micro syntax of Johns proposal will look like this:
>
>  <p aui= " symbol:(https://blissorsomething.com/uri.html)  easylang:(this
> is a long easy to understand discripiton, it could have 3 sentences .
> people are likely to have bugs by adding quotes.) numberfree:(this is a a
> discripiton which aviod's number. it could have four sentences and again
> people may add quotes or brackets that would add bugs".)
> simplification:critical"> some text  about this example </p>
>
>
> Can you spot the bugs?
>
> My counter proposal is to have easylang and numberfree as separate
> attributes. That will reduce the chance of author errors whilst keeping
> most of the advantages. It is a compromise (although I prefer the aui-
> approach)
>
>
> The above proposal would look like:
>
> <p aui= " simplification:critical symbol:(https://blissor
> something.com/uri.html)"    easylang="this is a long easy to understand
> discripiton, it could have 3 sentences . people are likely to have bugs by
> adding quotes."
>
> numberfree = "this is a a discripiton which aviods number. it could have
> four sentences and again people may add quotes or brackets that would add
> bugs." > some text  about this example </p>
>
>
>
> not perfect but less overloaded.
>
>
>
> All the best
>
> Lisa Seeman
>
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
>

-- 
*John Foliot* | Principal Accessibility Strategist

Deque Systems - Accessibility for Good

deque.com