Re: accessibility proposal Review...


The current accessMode vocabulary addresses this issue. There is "textual"
which is machine-readable text that can be rendered in lots of ways, and
there is "textOnImage" which can only be read with vision. (I don't know
if my emails have been cleared for posting to the public-vocabs list yet,
so this may appear there later.)


On 9/8/13 9:13 AM, "Liddy Nevile" <> wrote:

>I am just trying to understand the difference between text for reading
>- that can be rendered in lots of ways, say, and text on an image that
>can be 'read' but not rendered ... etc.
>On 08/09/2013, at 10:40 PM, Karen Coyle wrote:
>> On 9/8/13 7:49 AM, Liddy Nevile wrote:
>>> One of the problems that has arisen is that we have not managed the
>>> requirement of 'reading' in previous work. That one has to see text
>>> is a
>>> different thing from it being necessary for it to be read. So I
>>> want to
>>> know how we should make it clear that 'reading is required'.
>> Liddy, I'm not sure that this is the place to bring in literacy and
>> levels of literacy. After all, if there is sound, but it is sound in
>> a language I do not understand, then "hearing" is not the whole
>> requirement.
>> The education community deals some with the idea of reading /
>> understanding levels -- obviously, you don't want to give an 8-year-
>> old a college-level calculus text. For accessibility, I hope that
>> designating "text" or "sound" will be sufficient, and that most data
>> will have elsewhere information about what language(s) are available
>> and perhaps the required or preferred reading level of the user.
>> kc
>>> Also, what does it mean to have an 'allText' version as one of the
>>> available minimal sets.
>>> I think that there are lots of versions available is interesting to
>>> users (ie so they know it will be multimedia and, therefore by defn,
>>> interesting :-)) but it is also important to know that there is a
>>> version that requires only vision and reading, esp for those with
>>> hearing limitations, or only vision and hearing for those who can't
>>> read, etc.
>>> Also, I acknowledge that we have confused the logic a bit by having
>>> too
>>> much in accessMode. This is internal conflict, I think.
>>> I am now working on the idea of having seeing, hearing, touching, and
>>> reading as the base senses and then building a taxonomy by working in
>>> refinements of these so we can get to the detail that some might
>>> want.
>>> In fact, I think they should be able to specify more refinements
>>> (in the
>>> ISO case add them to the registry, perhaps) but that when a specific,
>>> detailed term is used, we will need to know how to work back up the
>>> taxonomy  to whatever is available eg if I have a requirement for
>>> fontsize 10 of MS Comic in yellow on blue, at least a system will
>>> know
>>> my requirements are related to seeing...
>>> I am not sure there is an easy way to specify all the permutations
>>> and
>>> combinations of minimal sets of accessModes for a resource even if
>>> that
>>> is a repeatable term.
>>> I find it hard to accept that in all cases the 'original' exists or
>>> makes sense so the solution of using accessMode and accessFeature (or
>>> mediaFeature) does not work well for me.
>>> Finally, there is the idea that the concepts we use for describing
>>> people's needs should be the same as we use for characteristics of
>>> the
>>> resource/service. I have tried to work with this but perhaps it is
>>> not
>>> the best way to go?
>>> Liddy
>> -- 
>> Karen Coyle
>> ph: 1-510-540-7596
>> m: 1-510-435-8234
>> skype: kcoylenet

Received on Sunday, 8 September 2013 14:02:29 UTC