Re: mix proposal

I agree John, Lisa would there be a situation where numbersFree is not or could not also include easyLang?
I just see this as maybe it is implied?
Also SimplifiedLanguage and easyLang we should probably just use one of those as that would be a HUGE point of confusion.

Thanks
EOM

Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
Twitter: @CLaPierreA11Y
Skype: charles_lapierre
Phone: 650-600-3301



On Sep 18, 2018, at 8:46 AM, John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>> wrote:

Hi All,

> Note the aui- option is still easier to parse and will probably have much better performance. this is a big issue for implementations.

My concern is that it adds additional weight to the authoring process, with a multitude of new attributes that authors will need to learn. This makes the 'language' too verbose, a comment *I'm* hearing about ARIA today: that there are too many attributes to remember there already. Additionally, I am unsure about how the performance claim can be made, as we really don't have a 'compare and contrast' example to prove that suspicion.

<opinion>
I continue to fall back to the mantra used during the HTML5 days: users over authors, authors over implementer(s), implementer(s) over code-purity. And so while I can be sympathetic to a point about implementations, if it's too hard to author, none of the implementations will have much value, as nobody will be authoring to them...
</opinion>


> Does the syntax work for you all (ie. space separated)?

While it "works", I do find it harder to parse. Personally, I like to see clear(er) demarcations of concepts or ideas. Using Lisa's example, but with the notation I suggested yesterday, I could write the same thing this way:

<p>Homes selling in the <span purpose="numberfree:('moderate price range')">low $300,000's</span>.</p>

versus:

<p>Homes selling in the <span aui-clarificationType="easylang numberfree" aui-clarification="moderate price range" >low $300,000's</span>.</p>


I personally find the second example more verbose, and harder to author, but that's but one opinion <grin>.

*************

I also have a question: is the difference between "easy lang" and "numbers free" that significantly different that we'd need to overload the example with both concepts?

It kind of reminds me of the old debate (in older versions of HTML) over the difference between <acronym> or <abbr>: yes, conceptually they may have differences, but functionally for the end user what is required is an 'expansion' (or explanation) of the abbreviation or acronym, which is one of the reasons why HTML5 deprecated <acronym> and only retained <abbr>.

I'm not rejecting the idea of using both, but I'd like to explore this a bit more, as it strikes me that "numbers free" is but a type of "easy lang" - but if I'm not understanding this please do help me to do so.

JF





On Tue, Sep 18, 2018 at 8:51 AM, Charles LaPierre <charlesl@benetech.org<mailto:charlesl@benetech.org>> wrote:
This does look interesting, and I like the idea if you don’t include the type easylang is assumed if that we think will be the most used option to cut down on amount needed to be authored.
Does the syntax work for you all (ie. space separated)?
Charles.



On Sep 18, 2018, at 2:22 AM, lisa.seeman <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>> wrote:

I am wondering about the following mix

1. A semi complex single attribute for context   <button aui="submit critical symbol(http://uri.html<http://uri.html/>) step(5)" > These are all content descriptors. This allows more then one context descriptors from fixed vocabularies and symbols. The con is it is slower to parse, slower to process and some more author error as the vocabularies are not separated. I am not sure if it works with things like css selectors.

2. Then we have a clarification  value pair for free text for easy lang, litral etc. this could be like

clarification="this costs less money" clarificationType="easylang numberfree"

If you do not fill in clarificationType the default is easylang.

Note the aui- option is still easier to parse and will probebly have much better performance. this is a big issue for implementations

I suspect we should have tow option and go to web apps and people like James for their opinion.
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<http://deque.com/>

Received on Tuesday, 18 September 2018 16:24:31 UTC