Madeleine,

I agree with you. 

But, I believe that it would be necessary to add one more: a form to
indicate, for example, that the font size of is invariable, to intention. 

This can useful for be determined educative contents that convey examples of
bad practices. Also the case that a certain element in a resource cannot be
accessible or can't become usable or adaptable, for certain types of needs
or preferences. For example, an image that explains an effect of the visual
perception, that hardly will be able to be described to a blind person from
her birth. 

Regards,
Emmanuelle 

-----Mensaje original-----
De: DCMI Accessibility Community [mailto:[log in to unmask]] En
nombre de Madeleine Rothberg
Enviado el: jueves, 08 de febrero de 2007 20:38
Para: [log in to unmask]
Asunto: Re: Not accessible or not adaptable.

Elaine,
Handling those individual needs is exactly what the metadata is designed
for. I agree completely with your position. The new items I suggested below
are very specific, allowing the resource to be labeled with precisely the
ways it is or is not accessible (font color, font size, mouse use, visual
versus text, etc). This is not a blanket statement of accessible or
inaccessible. It is intended to be matched to each user's profile of
accessibility needs. But to do that well, we need a way to record when a
resource has been evaluated and found to be missing a particular access
feature that some users need, to distinguish it from a resource that hasn't
been checked at all (or hasn't had that particular feature evaluated).

-Madeleine

On Feb 8, 2007, at 12:48 PM, Pearson, Elaine wrote:

> Accessibility or inaccessibility depends on the user. It is too 
> simplistic to say something is accessible or inaccessible. It depends 
> on who is using it. For someone with good vision but learning 
> difficulties, and alt tag may be of no use at all, nor would a text 
> only page, whereas it may be very satisfactory for a blind user. A 
> sight that is largely graphics or animations may be great to the user 
> with learning difficulties but no use to a blind user. There is no 
> such things as accessible or inaccessible, so stating something in 
> negative terms is not necessarily helpful.
>
> Elaine
>
> ________________________________
>
> From: DCMI Accessibility Community on behalf of Madeleine Rothberg
> Sent: Thu 08/02/2007 14:33
> To: [log in to unmask]
> Subject: Re: Not accessible or not adaptable.
>
>
>
> I think Lisa has stated the problem very clearly:
>
> On Feb 8, 2007, at 4:02 AM, lisa wrote:
>> I do not think anyone care about the intent. The question is this 
>> known to be inaccessible, or is it just a case of no one wrote the  
>> meta data to say it is accessible.
>
> And I think that we have not entirely solved that problem in our 
> metadata model. For some areas, we have. If you state that a resource 
> contains visual content but do not state that it has text 
> alternatives, it is clear that it is inaccessible to someone who can't use
visuals.
> But for the interface flexibility and display transformability 
> elements, we may need to enhance the vocabularies to permit stating 
> the negative result. Currently the vocab for interface flexibility is:
> full_keyboard_control, full_mouse_control (ISO version) or keyboard 
> only control, mouse only control (most recent DC page I could
> find)
>
> The intent of this element (when I proposed it) was to inform users 
> who must use the keyboard whether they could entirely control the 
> resource with the keyboard. It was tricky to get the wording right to 
> imply that concept rather then the negative one -- "keyboard only 
> control" sounds like it means your mouse won't work. I think the ISO 
> wording is closer to conveying the positive meaning, though I welcome
other suggestions.
>
> But the need Emmanuelle raised, and Lisa has restated, is to have both 
> positive and negative statements available, such as:
> full_keyboard_control
> keyboard_required
> full_mouse_control
> mouse_required
>
> With that vocabulary, we can express that we have checked a resource 
> and it requires the mouse. With the two-item vocabulary, we would need 
> to skip that element and not express the result of our test if we find 
> that the resource requires both mouse and keyboard to be used. (One 
> distracting but important side issue: users who can only use a mouse 
> generally use an onscreen keyboard, so they need to have an 
> appropriate profile to indicate they can use either mouse-driven or 
> keyboard-driven resources. It is the users who can't use a mouse who 
> have more trouble here, I believe.)
>
> The list of display transformations is longer, but putting a not 
> prefix in front of each one may be fine:
> variable font size
> invariable font size
> variable font face
> invariable font face
> variable foreground colour
> ditto
> variable background colour
> ditto
> variable cursor
> ditto
> variable highlight
> ditto
> variable layout
> ditto
> variable reading rate
> ditto
> structured presentation
> unstructured presentation
>
> This doubles the size of the vocabs, but I think it meets an important 
> need. I am interested in your opinions.
>
> -Madeleine
>
> ----------------------------
> Madeleine Rothberg
> Chair, IMS Accessibility Special Interest Group Director of R&D Carl 
> and Ruth Shapiro Family National Center for Accessible Media at WGBH 
> http://ncam.wgbh.org <http://ncam.wgbh.org/> 
> [log in to unmask]
> 617-300-2492 (voicemail)
>