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

people mess up the syntax around embedded values, for example  aui= easylang:("this") "  is more complex then a simple and familiar easylang="this " All the best Lisa Seeman LinkedIn, Twitter ---- On Tue, 25 Sep 2018 18:21:10 +0300 John Foliot <john.foliot@deque.com> wrote ---- 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: -- John Foliot | Principal Accessibility Strategist Deque Systems - Accessibility for Good deque.com 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://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 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, Twitter