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.
