I want AccessibilityProperties to do more because it already exposes support for accessibilty in a more generic way that could easily be supported on other platforms. By adding a cross-platform set of role identifiers to it, it stays that way. I also want to make sure that complex controls can be made accessible. At times, I found AccessibilityProperties gave me better spoken results in a screen reader, but I couldn’t expose some important sub-controls. I’d be happy with just those two things, honestly. I say that if Adobe can build a set of visual UI controls to work cross-platform by finding reasonable compromises, we should be able to make the same controls non-visual by finding the same nice common ground.

I spent a month documenting AcessibilityImplementation and how it works through MSAA while working at Yahoo!… including all the bugs that made some of its functions less capable than if you tried to implement them in a native Windows app. Yes, it is still more powerful than AccessibilityProperties, but the walls it threw up were enough to frustrate me beyond belief and swear it off. Its worst fault, though, is that it’s an ugly hack in an otherwise cross-platform runtime. You know the only reason it’s there is so that Adobe can declare on their feature lists that the official Flex/Flash UI controls are accessible.

Getting into hierarchies, roles, default actions and states are non-trivial, and tightly bound to the controls implementation. That’s not even mentioning events. I can’t see a good way of implementing this in a generic way via AccessibilityProperties (though because I can’t see it doesn’t mean it’s not possible).

Then again, I’ve also not had any problems with AccessibilityImplementation. It’s almost completely undocumented, but it works well if you can piece together the details.

I understand and agree that Adobe and Apple should be working together to expose Flash controls to Apple’s accessibility framework. Adobe should also be fully documenting AccessibilityImplementation in Flash (as they did with Flex).

Do you know if Snow Leopard added ARIA support to VoiceOver? Last I’d heard (and it’s been a while) ARIA was partially implemented in Safari, but VoiceOver wasn’t playing nice with it.

Thanks for the discussion. Is always nice to talk to someone else that cares about this stuff in the Flash community.

Since AccessibilityImplementation sucks so much, I happen to like AccessibilityProperties better, even though it is seemingly limited in comparison. I found it to be much more predictable. If AccessibilityProperties supported the ability to set roles and expose children as accessible objects, it would be perfect for me, and that’s the point I was trying to make. Ideally, I would like to see WAI-ARIA roles so that Flash accessibility can finally be cross-platform and standardized instead of tied to Microsoft’s implementation.

At least two of your points are incorrect, though understandably so as the documentation is so spotty:

“The AccessibilityProperties class doesn’t support roles”

Not true. get_accRole(childID:uint)

This method should return an MSAA role identifier.

“AccessibilityProperties doesn’t expose the display list hierarchy”

Technically true, but as the developer that’s your responsibility. Use the getChildIDArray() method to list your children, with “0″ being the object itself. the ID’s correspond to the childID parameters of the other methods in the AccessibilityImplementation class.

I’m planning on writing a how-to on this, but it’s likely not an overnight thing. If you’re interested I can send you the link when done.

Jer

The point of accessibility is that everyone can access a web page. The blind/visually impaired. Those with motricity problems. Those with cognition problems. And that, no matter what interface they may choose to use. Once you start making exceptions, you’re not accessible anymore. Adobe going for a Microsoft proprietary solution doesn’t only undercut disabled Mac users, but Linux ones, and G3 phones’, and all other non-IE – or more likely, non-Microsoft – users. (Could anyone swear that no disabled person will ever use a Blackberry?) So let’s forget the Windows/MacOS “war” altogether, and focus instead on letting everyone access a web-based solution. On that count, Adobe’s decision is a bad one. They have chosen to go for a quick solution and dropped its intrinsic purpose along the way; they will have to redo the job later on.

Besides, I can’t see a governement agency tell their web-site users: “Oh, by the way, if you are a disabled MacOS user, sorry, you won’t be able to use all our functionalities.” It doesn’t matter the number, it takes only one who complains to get them into trouble, and they don’t want that.

I develop web-based e-learning courses for internal use, where the computer environment is very controlled; yet, once in a while, a course gets demoed outside. Then I have no longer control on who use it with what browser and what computer. I can’t allow such a faux-pas as deliberately leaving someone out in the cold. So as long as Flash isn’t fully accessible, I will ignore Flash-only solutions.

(Sorry for being late to the show – and for having this post sounding a little too much like a rant.)

I believe you’re right that most, if not all, of the people who need screen readers are on Windows. It’s possible the cause of that is because Apple has provided poor APIs for such technology. I’ve played a bit the VoiceOver screen reader in Leopard on my Mac, and the situation seems to be getting better.

Personally, my primary development machine is a Mac. Obviously, I develop Flash content that will be seen on Windows too. As I developer, I don’t want to be required to switch to Windows every time I want to test my project with a screen reader. If I can do most of the testing on my Mac, that would be ideal. It’s similar to how I would build a webpage. If I can do most of the testing in Firefox, I’m happy. Once the page is nearly complete, only then do I fire up IE or Safari and ensure that those browsers render my webpage the same way.

I’m not sure on improvements to browser-plugin access to Mac text-to-speech routines… I know other folks here track it, and are interested in implementing it if possible, but I haven’t heard yet that it’s possible.

The reason I ask about the use-case is that most of those who use screenreaders have been on Windows, because of system-level support so various apps can communicate with various screenreaders. I don’t know how many people who *need* text-to-speech use Macintosh… last I heard they were uniformly on Windows. But my prior info could be outdated, or it could be that you need text-to-speech yourself for effective preview. Knowing the exact situation could help me do better lobbying inside Adobe.

tx, jd/adobe

Yeah, I totally hear you that it “will” be an issue… and the fact that it’s often difficult or impossible for Flash to compete for such projects makes me think Flash is very lacking. But, it’s also hard for me to care when my clients aren’t willing to pay for it. Don’t get me wrong–I’ve actually given papers that make good arguments for why you should make accessible sites (and for reasons beyond “it’s the right thing to do”.

If Flash were to easily and effectively support accessibility–say, even Mac too… then would anything change? Probably not. But… if they don’t improve some things (“improve” meaning make it so people are likely to use it) then it DEFINITELY won’t change.

1) Good to know. I wonder if the semi-new VoiceOver in Tiger/Leopard has added support for browsers compared to what has been available “for a while”? If not, I hope Adobe is communicating with Apple or browser vendors to ensure that this becomes available in the future.

2) I’m not sure what exactly you mean here. I’m not a blind user, but I want to make sure my Flash work is accessible to anyone, and Flash Player doesn’t allow me to do that when a blind user has a Mac.

3) Yes. I want to specify the type of UI control a display object in Flash represents.

4) There are two goals, but I desire one or the other, not both.
a) An undocumented class (AccessibilityImplementation) should be documented.
b) This class is clearly Windows-centric, and it’s not even a complete implementation. A better cross-platform API with similar features should be made available instead.

Background info:
o Mac has had text-to-speech for awhile, but last I heard there weren’t hooks accessible to browser plugins.
o (For Mac text-to-speech, I’m unclear on the user case… are you thinking of the blind on the Mac, or your own evaluation of their experience, or other…?)
o I hear one of the requests as “I want to specify that an object is a button, not a graphic”… did I distill that correctly?
o I wasn’t able to see the goal in the MSAA/AccessibilityImplementation part.

jd/adobe