Re: accessibility proposal Review...


for ever we have had this problem that dc:type and dc:format have to  
be used together for accessibility - so we know the problem and  
hopefully will sort it !


On 08/09/2013, at 11:43 PM, Karen Coyle wrote:

> Liddy,
> Now I see what you mean. And it is very complex. Are a printed page,  
> a photo of a page, a gif with some letters, and digital document all  
> text?
> The Dublin Core type vocabulary says:
> "Text: Examples include books, letters, dissertations, poems,  
> newspapers, articles, archives of mailing lists. Note that  
> facsimiles or images of texts are still of the genre Text."
> But I think is is assuming that the user is sighted. There are many  
> gradations, both of text and of sightedness -- with a magnifying  
> glass some VIPs (visually impaired persons) can read non-digital  
> text, but if it is unclear, or on a medium that does not fit with  
> their reading device...
> I think it may be necessary to have "visually accessible text" vs.  
> "machine-interpretable text". I can't imagine how you would fill in  
> all of the variations.
> Good luck! :-)
> kc
> On 9/8/13 2:13 PM, Liddy Nevile wrote:
>> 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
>>> ph: 1-510-540-7596
>>> m: 1-510-435-8234
>>> skype: kcoylenet
> -- 
> Karen Coyle
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet

Received on Sunday, 8 September 2013 13:52:06 UTC