Re: Custom table cells and NSAccessibilityExceptions
Re: Custom table cells and NSAccessibilityExceptions
- Subject: Re: Custom table cells and NSAccessibilityExceptions
- From: James Dempsey <email@hidden>
- Date: Tue, 11 May 2010 15:08:42 -0700
On May 11, 2010, at 2:20 PM, Bill Cheeseman wrote:
>
> On May 11, 2010, at 4:40 PM, Christiaan Hofman wrote:
>
>> Are they all required? And what to do when some attributes don't have aren't meaningful or can't be supported in a particular case? For instance I have a situation where I want to represent a text, but I have no way to get the layout of the text, so I can't implement attributes like NSAccessibilityRangeForPositionParameterizedAttribute.
>
>
> I think it is fair to say that your application's design should dictate what accessibility features you can or will support, rather than the other way around. Accessibility is what I think of as a "secondary" feature.
I think we're getting off topic, but I did want to comment.
I would disagree with this characterization as a "secondary" feature. The accessibility representation of the user interface is a verbal, structural, and semantic representation of an application's user interface. For sighted users, that is communicated visually by bitmaps on the screen - but the user interface that is designed is more than just an image.
As you design a UI, you are designing not just the visual appearance of the elements, but the meaning and relationship of the elements - and that is exactly the information that is most important to accessibility.
When you represent those elements using standard Cocoa controls and views, we can automatically infer the structure and a great deal of the meaning - and in those areas where we can't, it is often a matter of adding simple descriptions and relationship information to elements in IB. In these cases, the accessibility is not secondary, but intrinsic to what you have built, except for clarifying a few points of description that the framework cannot guess.
When you represent the UI in ways where the semantics are not well-defined by the API - then you essentially use the accessibility APIs to programmatically indicate the structure and semantics that you've implemented for the benefit of AX clients like VoiceOver. (Custom views are a good example of this, you can draw anything in any number of ways, and we don't really know that you intend this piece of a view to be a button, and this other piece to just be an image, etc. - but you know all of this when you write the code).
Of course, in practice, there are cases where the way an app is implemented make it very difficult to report to accessibility the precise semantic meaning - but as a rule of thumb what accessibility reports is in a way a very pure distillation of the semantics of the UI you designed in the first place. So it is hard for me to think of it as "secondary".
In this particular case, anything that reports itself as being a text area / text field / static text, ideally would report all of the text parameterized attributes. It is much better for a VoiceOver user that the element be reported and that it report an AXValue than not be reported at all.
> Your primary responsibility is to design and write an application that performs whatever operations you have defined for it. Then, in order to make it easy for persons with disabilities to get as much value as anybody can get out of your application, you implement whatever accessibility features will let them perform the operations that your application is capable of performing.
>
> Using accessibility, a person with disabilities should be enabled to do neither more nor less than any other person can do with your application. For example, if your application doesn't need or can't get layout information for anybody's use, then you shouldn't try to make layout information available for a person with disabilities. If you're concerned that somebody might be surprised by what your application can't do, document it.
In this case Bill - every sighted user can find out just by looking at the text which snippet of text is on the third line, or where on the screen a particular word is, to name a few examples. These are pieces of information that are available at a glance to a sighted user, and so again, ideally the attributes that support an assistive app to use similar information would be present for all text elements. In practice that may not be realistic in some cases.
But, I agree that the interface you expose through accessibility should enable doing what the graphical interface allows, and not more or less. That is a rule of thumb we try to follow.
-James
--------------------------------------------------
James Dempsey
AppKit Engineering
Apple
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden