Yuma, This is great and thank you very much for your efforts and sharing this information. I think this would be worth sending to the folks at Agile SOftware (1 Password folks). This has been the one thing I would like to work with APple on is raising awareness in some fashion to developers. I realize it is not Apple's job to be in the advocacy business perhaps and maybe there is something that mentions all this from the initial step in developing software under Cocoa. However, if not, it would be nice to slip some language in somewhere that would call attention to being inclusive when a developer is creating software. I know this topic has come up for discussion from time to time and it seems progress has been made with iOS software developers and maybe this new app store concept for the desktop is an avenue for getting accessibility out there. Just tossing my musings out there for further consideration.
Scott On Nov 27, 2010, at 8:10 PM, Yuma Decaux wrote: > Hi list, > > I just looked into apple's accessibility guidelines, and skimmed over it to > better understand where NSaccessibility classes can make standard coco > elements more visible to blind uusers. > > Here is the template request message: > > Hello, > > THis mail is in regards to a general desire from the blind community to > provide itself greater productivity and features when we purchase your > software, and i've dug a bit deeper into the guidelines presented by Apple in > their coco framework, namely the accessibility API which reflects on all > standard interface elements present in the majority of mac software for intel > macs. > > I wanted to give you guys a headstart in making your coco native application > accessible to blind users as this would greatly enhance our experience in > using your software, as well as allow you to grant more sophisticated > elements in the interface of your applications. > > > To start with, here is the outline as per edited on the apple developer > center, touching on the need to standardize applications to allow a wider > audience to access your software. > > https://developer.apple.com/ue/accessibility/accessibilityincocoa.html > > > As you might see in the above article, accessibility APIs and descriptions, > available in accessibility.H are bound to many standard ui element classes, > and are also hierarchy relevant, whereas an accessibility class can be > plugged to hierarchical elements such as item lists and interface areas, > rendering the whole accessible by just plugging the accessibility classes. > > Those of main interest are accessibility role and description. > > The Former allows screen readers to know what an element on the interface is, > a button, a scroll bar, and each individual elements of complex elements (a > scroll bar has 5 elements, the top and bottom buttons, the underlying bar, > overlay bar and the holder of all the elements. > > The second important class, description, is like a tag which will tell the > screen reader what the function of the button or list item is, mainly either > a static tag as in a sync button would need a description of "sync" and > dynamic elements would pull from a value given to the item on the list by > default for sighted users. > > > These examples are for standard UI classes, and customized ones can also have > the "accessibility plug" appended to them. > > > I apologize for this longish mail, but after a few years understanding what > elements are inaccessible due to graphic interpretations making buttons > unlabeled, or descriptions unnecessary due to dynamic text being visible to > sighted users but not obvious for screen readers. i wanted to make a template > and try to help you guys apprehend the concepts for making those already > accessible elements more descriptive for blind users. > > > In hopes that this might engender some interest in applying those standards > requested by Apple, i just wanted to let you know that your software does > make an enormous difference in my life as it provides me with the tools > necessary to stay active and participate in the growth of the mac eco-system. > > > Sincerely, > > > > I believe that since most macs and applications have switched to coco, > instilling more head-start specifications to developers would help them know > where to start and how accessibility apis are structure and mirrored with > standard code. > > When reading this article, and looking into the header file as well as the > API, it seems very straight-forward, and perhaps having a repository of > either standard UI elements and their respective codes, as well as looking > into the custom elements sometimes necessary for certain applications, such > as garage band's timeline features, deconstructing the hierarchical orders of > these master elements would be very helpful on a mid-term. > > If anyone has some information on these issues, coders or researchers, please > don't hesitate to contact me as i will try to make a unified document which > would be used to hand out to developers in an easy concise method. > > Best regards, > > Yuma DX® > > > "Light has no value without darkness" > > blog: http://www.theblindsamurai.com > twitter: http://www.twitter.com/triple7 > Tel: +64 210 22 77 190 > Phnom Penh: +85589900095 > > > > > > > -- > You received this message because you are subscribed to the Google Groups > "MacVisionaries" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/macvisionaries?hl=en. -- You received this message because you are subscribed to the Google Groups "MacVisionaries" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/macvisionaries?hl=en.
