Well, We have an app rating system for IOS. Applevis does a nice job at this. I don't hate the idea of an accessibility rating system. In fact, I'm working on one for android apps right now. I just don't think it provides the level of education and oversite that you would get if you built accessibility debugging rules directly into the compiler, provided direct education targetted at accessibility, and then backed it up with a component of the internal review process where-by apps would not be posted for distrobution unless they met certain accessibility cryteria.
Benefits of this approach are that we have some assurance of quality. We also have some assurance that we can invest in an app and still be able to use it down the road. App developers are aware of accessibility concerns from the ground up and then they have fewer accessibility bugs to fix later. We persecute them less. Finally, apps would be accessible for all persons with disabilities and all apple accessibility tools, not only blind people using voiceover. It's amazing we forget that there's a great wide world out there beyond us sometimes. Drawbacks are, there is a perception that building accessible apps is limitting. It's a misperception, but it would be a big change and that would make developers feel put upon. Advantages of an accessibility rating: It would theoretically give developers some idea of how many of us are out there. Developers would be publicly rewarded for accessibility or publicly demoted for inaccessibility. Users would know what to expect as long as some one had rated the app they want to use. Drawbacks: With over 1.5 millian apps in the store, there's no guarantee some one will have used and rated your app. Theoretically, users who don't use accessibility could impact the rating. It's week. Rewards and punishments are all well and good but with no obligation on the part of the developer, the rating system has no teeth. I'd also like to point out the ethical concerns. We have been talking about this on the android list, and it seems worth repeating. First, in the new paradigme, accessibility is built directly into our hardware device from the manufacture. The manufacturers have not taken this all the way, but they need to. Part of the manufacturer's commitment to accessibility must include comprehensive training, debugging tools, and at the end, a refusal to distribute apps that do not meet basic accessibility cryteria. As the manufacturer of both the device and the software distribution model that supports the user experience, I believe these companies have shouldered the social and economic responsibility for the quality of their apps, but have not conducted good oversite towards app accessibility as they have in security and in other areas. Second, The Freedom Scientifics, GW Micros, and Humanwares, of the world are a thing of the past and becoming less and less relevant every day as they refuse to adapt and find ways to grow in a world where accessibility is in the mainstream. That means we no longer will have these people who we used to pay thousands of dollars per person in order to bolt on accessibility for us. That's right. If you buy an IPhone for work, and an update to pages renders the program inaccessible, no one is going to come along and script it back into functionality for you to the tune of $200 per hour. That necessarily places more onus on developers to get things done right. You may say that isn't fare to developers and you may be right, especially with the lack of education and oversite being leveraged towards accessibility, but life isn't fare. Have fun, Erik Burggraaf The great amazon gift card giveaway begins friday june eleventh at 5 pm! The more who donate, the more chances there will be to win! Click here for detales. http://www.fundme.com/en/projects/6287-Orientation-and-mobility-training-for-the-blind On 2014-07-11, at 1:36 PM, Robert C <[email protected]> wrote: > This is exactly what I was suggesting not too long ago and was pretty much > shot down. We need this type of rating system. If an app is rated as > accessible, then we might have a hope that the developer just may be > interested in improving his app should there be some shortcomings. We gotta > start somewhere. > > The 2 level rating system makes perfect sense. Its NOT real usability we > want, its knowing that an app may be accessible and we then can decide > whether to buy or not. I do not hesitate to try free apps. I do not buy a > paid app unless I know its at least partly accessible. This might be a good > idea to develop apps in such a way that they are free to try and if we like > it, do an in app purchase to release its full functionaility. > > Usability can be subjective, yes. That holds true everywhere. The above > idea would allow us to test this for ourselves. > > Quote of the nanosecond . . . > Like a cult, but without the animal sacrifice. > --Mary Kay > Robert & Annie Yanni ke7nwn > E-mail- > [email protected] > > On 7/11/2014 8:55 AM, erik burggraaf wrote: >> Chris, I think you have to cut your 4 star rating down to two for these >> purposes. >> >> An accessibility issue, that where there is a barrier to the use of the >> feature. >> A usibility issue, that where something works, but is unintuitive. >> >> You can then test for certain things. For example, any modern compiler can >> tell you if you are missing a semicolon at the end of a line, if a procedure >> is not closed properly, or if a variable is not declared properly. In the >> same way, it can also tell you if any object does not have labels and or >> help tags. Many compilers do this anyway, but labels are treated as >> warnings when they could and should be upgraded to something a bit more >> alarming. >> >> Compilers could test for some rules making sure that custom controls are >> connected to the accessibility API, and those should be fatal errors. If >> there were a way to iliminate the human element from all software testing >> and still have programs that ran cleanly and looked fantastic, they would >> have found it by now. We just need the same level of caution afforded to >> accessibility. There will always be diverse levels of usibility, but a >> standard for software whereby it could not be released without the minimum >> level of accessibility is a real, essential, and highly achievalble goal. >> >> BEst, >> >> Erik Burggraaf >> The great amazon gift card giveaway begins friday june eleventh at 5 pm! >> The more who donate, the more chances there will be to win! Click here for >> detales. >> http://www.fundme.com/en/projects/6287-Orientation-and-mobility-training-for-the-blind >> >> >> >> >> >> >> On 2014-07-11, at 11:18 AM, "'Chris Blouch' via MacVisionaries" >> <[email protected]> wrote: >> >>> The hard part is that accessibility is a continuum, not a boolean checkbox. >>> You can never, or at least seldom, say an app is fully accessible. At some >>> point it's just like saying an app has a good user interface. That's highly >>> subjective. Sure the basics are obvious like missing button labels or >>> undiscoverable controls, but beyond that there be dragons. When I check >>> apps for accessibility I give them a priority ranking 1-4. P1 blocks access >>> to a major feature, P2 blocks a minor feature, P3 makes a major feature >>> difficult to use, P4 makes a minor feature difficult to use. I usually get >>> a good response from developers on P1s and even some P2s but that leaves a >>> pile of hard to use stuff because those bugs never get high priority. The >>> typical developer is asked to implement 100 things but only given enough >>> time to do 50. So they've already had to dump a bunch of stuff. Then to ask >>> them to dump more features to fix some accessibility bugs, well, that's a >>> hard sell. Some care and will > do the 'extra' work or at least fix the worst/easy things but some are > already under a lot of pressure and really can't spare the cycles. >>> >>> CB >>> >>> On 7/10/14, 6:12 PM, DD wrote: >>>> >>>> http://www.marco.org/2014/07/10/app-review-should-test-accessibility#tk.rss_all >>>> >>>> >>>> XB >>>> >>> >>> -- >>> ¯\_(ツ)_/¯ >>> >>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/macvisionaries. For more options, visit https://groups.google.com/d/optout.
