Hi, Let me just add that the wwdc this year has put a highlight on accessibility to the developers attending or downloading the workshop videos, so saying that apple has put accessibility to the bottom of the list is untrue. In addition, now all standard UI controls in xcode are by default accessible. This has engendered an effort from oracle with its javafx framework to render all their controls accessible for both mac and windows.
When it comes to custom APIs, I remember there used to be a tool called accessibility inspector which allows the developer to check the hierarchy of controls and scenes in an application to see which control gives what accessible output, or what voice over will announce. Usualy custom controls are 3D based or image based, which requires an effort from the developer to handle what is said, how and what triggers it, which is a set of coding behaviours that need to be placed on top of the custom control. Cheers, > On 21/06/2015, at 1:06 AM, Littlefield, Tyler <ty...@tysdomain.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello: > First, it's always a really hard discussion when someone with little > to no development experience talks about how things "should" be done > because they're usually way off. So I'll explain how things work > currently. > > A long long time ago, in a galaxy far far away Windows and OSX > developers all used different APIs than they do now. A majority of > windows applications were written in C/C++ or delphy, with a couple > others thrown in. OSX used C mainly (maybe c++) and they used the > Carbon API. > > Carbon and Win32 basically let people do the same stuff, create > windows, etc. but where the problems came in was that it gave a lot of > control to the developer, so the developer could basically write up > all sorts of cool new things in their controls. Now that people > started moving more toward using vb.net, c# etc for Windows > development (because using the win32 API is not fun--I have a media > player I'm writing mostly in c), as well as people moving toward > Cocoah, this problem is going away for the most part. > > Now the problems we face are a lot smaller. Windows had MSAA and UIAA > for providing information to the screen readers, and Cocoah has its' > own accessibility frameworks. As you're using a framework they > control, it's really easy to make most things accessible by default. > But again, the issue is with custom controls. Many times a developer > wants something new in their app, because it looks cool or because the > control can provide custom functionality that another one does not. > This, I believe is the issue you are running into. So rather than > Apple do what Windows does as they're already doing that, there needs > to be something that tells developers when their controls are broken. > This really should be up to the developer to fix, mostly because Apple > can either say nothing with custom controls gets into the app store > (bad idea), or they would have to fix it themselves. Maybe some sort > of testing framework could be created to determine if everything works > as it should. The goal would be to create an instance of that control > and determine if it has the requisite properties. > > Sorry for the rambling jumble here, no coffee yet! > HTH, > On 6/20/2015 8:58 AM, Devin Prater wrote: >> Hi all. So I’ve been thinking about the accessibility of both the >> Mac and Windows apps. While Apple has clearly laid out the details >> of how the accessibility API works, developers usually don’t know >> them because either its way down in the developer guides or the >> developers just don’t worry about that kind of stuff. This isn’t >> just complex apps, these are little apps too, the apps you’d expect >> to work flawlessly, like Atlantis, the MUD client for mac. I’d love >> to be able to use it, but nope. Why not, I ask Apple. “Its up to >> developers to make their apps accessible.” Why? Why should it be >> the developer’s fault if an app they make can’t be used by the >> system screen reader? I think that the accessibility engineers have >> been going about this the wrong way. First of all, if a developer >> uses a custom development that doesn’t support accessibility, there >> is no way of fixing that, and we can’t expect developers to rebuild >> apps just for us. Take the Alter-aeon MUD app for example. Now, >> maybe an app is pretty accessible but maybe just needs a little >> more tweaking that the developers just won’t be bothered with? Or >> maybe an app like open-emu, where the preferences dialog is almost >> accessible but the tabs along the top of the window cannot be >> reached via keyboard. We can’t expect developers to get it all >> right. I think that voiceover should copy what other windows screen >> readers have done in the past and has made countless apps >> accessible. Just get information about what’s on the screen and >> make that available to voiceover as well as the os x API’s. >> > > > - -- > Take care, > Ty > twitter: @sorressean > web:http://tysdomain.com > pubkey: http://tysdomain.com/files/pubkey.asc > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBAgAGBQJVhYF5AAoJEAdP60+BYxejDoEH+wVpVznk5HoG3cBrFB8/J3Ew > isf6MYlGPVyC/n6WAiJhtndM3Ih91oXPmsqh/V9sUjPZNY+VDo52byHcxBW5bAWL > 4sNaU6p3d5a/jOicTYJAlP5GBsyHcMmTalSpNwZUVNlp17rfAe6TnsOodgiVvWUR > PkhlO5OmYfnJMa++7i8KnAjVdsGi1OHN1AWlHwknnPp1Qu1CAPOWHe/ZGPfrD44H > JcaTGFnGcDS93Gz/j7qPvjr5NI37mE8pIUnyotTx5H+okTpt9CWjOgMVmTwKDxxb > PjHk4u85/3Og2uxVyE8BcCVafmpKHAfX6jOTrJJoMKJ+8fZxA8ZRVue+dasqCWg= > =PAQw > -----END PGP SIGNATURE----- > > -- > You received this message because you are subscribed to the Google Groups > "MacVisionaries" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to macvisionaries+unsubscr...@googlegroups.com. > To post to this group, send email to macvisionaries@googlegroups.com. > Visit this group at http://groups.google.com/group/macvisionaries. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "MacVisionaries" group. To unsubscribe from this group and stop receiving emails from it, send an email to macvisionaries+unsubscr...@googlegroups.com. To post to this group, send email to macvisionaries@googlegroups.com. Visit this group at http://groups.google.com/group/macvisionaries. For more options, visit https://groups.google.com/d/optout.
