Re: Schema.org accessibility proposal Review...

coming in with a clean plate .... and hoping this mail gets to everyone?

...

As we are about to discuss the terms for the new AfA in ISO  
(tomorrow), and esp for the application profile in which I aim to have  
the minimum set of terms as a guide for people, I want to agree with  
the priority of having the same way of marking up things for  
schema.org, ISO, etc - as far as possible.

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'.

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

Received on Sunday, 8 September 2013 06:49:57 UTC