Re: wiki page for implementation options for symbols

Hello Lisa, All,

Lisa, I remain both confused and concerned here. As I read your proposal,
you are effectively saying you expect content authors to do this:

<img symbol="Content" href="mysymb.bmp">  <img symbol="Authors"
href="mysymb.bmp">  <img symbol="will" href="mysymb.bmp">  <img symbol="be"
href="mysymb.bmp">  <img symbol="writing" href="mysymb.bmp">  <img symbol="with
" href="mysymb.bmp">  <img symbol="symbols" href="mysymb.bmp">

Respectfully (and putting aside the fact that browsers do not render .bmp
files), no mainstream content site is going to do this - we learned that
lesson years ago with "text-only" pages for screen readers. Your proposal
appears to call for a secondary (alternative) content page, which simply
will not surface on the web, certainly not at scale.

This brings into question an evaluation of our goals here: is the goal to
provide a mechanism for specialty pages specially authored for a limited
sub-set of the web community, or is the goal to create a mechanism that
allows for 'transformation' of text to symbols? The demonstration we saw 2
weeks ago from Mats showed us a 'tool' - a plugin - for Libre Office that
did the 'transformation' on the fly, and programmatically at that. What he
did not show us was a mechanism where each symbol was laboriously applied
to the document in a hand-authored fashion.

I suspect what we need to do is instead find a means whereby we inform a
'tool' *which* symbol set to reference: either one linked-to online to an
open source collection like Bliss, or alternatively to a localized symbol
set the individual user has downloaded to their machine (or.
al;ternatively, one that is embedded into the tool itself).

In either case however, the "writing" of the transformed text into graphic
files will be handled by the helper-app / tool: there is no need for any
human author intervention when the transformation happens. The tool
outputs <ing
src="symbol_X.png"> <ing src="symbol_Y.png"> <ing src="symbol_Z.png"> based
upon a programmatic mapping table associated to the helper app (and / or
the symbol set) and effectively "overlays" that content on the screen.

This maps to what I saw 2 weeks ago (April 22nd) and has always been what I
sort of expected our outcome would be.

JF




On Sun, May 5, 2019 at 9:49 AM lisa.seeman <lisa.seeman@zoho.com> wrote:

> Hi Folks
>
> To help us gather our thoughts I started a wiki page to add implementation
> options for symbols
> I am sure it is incomplete so please add options, advantages,
> disadvantages or identify anything you think should be changed!
> It is just to get the ball rolling.
>
> See:
> https://github.com/w3c/personalization-semantics/wiki/Options-for-symbol
>
>
> All the best
>
> Lisa Seeman
>
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
>

-- 
*​John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com