- From: Liddy Nevile <liddy@sunriseresearch.org>
- Date: Sun, 8 Sep 2013 23:13:27 +1000
- To: kcoyle@kcoyle.net
- Cc: public-vocabs@w3.org
Karen 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. Liddy 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 > kcoyle@kcoyle.net http://kcoyle.net > ph: 1-510-540-7596 > m: 1-510-435-8234 > skype: kcoylenet >
Received on Sunday, 8 September 2013 13:13:59 UTC