Erik,
Many good points. Applevis, being dependent on user input would
serve well fot the "usability" factor. Developers can keep an eye nn
this to follow the reveiws their apps.
If developers were encouraged to build in accessibility as a norm,
half their work is done. If they do already, then there must be better
oversight as things break as you pointed out in your example. That could
be disastrous in some cases. Case in point that comes to mind is in iOS
6 I believe when some braille displays were unable to connect.
It has to start somewhere.
Quote of the nanosecond . . .
Whether they find a life there or not, I think Jupiter should be called
an enemy planet.
--Jack Handey
Robert & Annie Yanni ke7nwn
E-mail-
gone.to.da...@gmail.com
On 7/11/2014 11:28 AM, erik burggraaf wrote:
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 <gone.to.da...@gmail.com> 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-
gone.to.da...@gmail.com
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"
<macvisionaries@googlegroups.com> 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 wil
l
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 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.
--
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.
