[Blindmath] How useful is a GUI to blind users?
Ken Perry
kperry at blinksoft.com
Tue Jan 10 15:46:38 UTC 2012
I am not arguing that fact in fact your example might just simply have
something that returns this is a graphical
I agree with you on this point as well. In fact if you go to windows paint
you will find the drawing area is not accessible but you do know it's a
drawing area. My point is that 95 % of software could be made accessible
mainly by forcing the toolkits to have forced accessibility roles. Take all
the games in windows 7 that have not been accessible as far back as the
first windows OS. Suddenly Microsoft forced their programmers to follow
their accessibility guidelines and now you can play those games with the
simplest screen reader. Heck as soon as windows 8 comes out there won't be
a need for screen reader for most Microsoft Aps. On a difficult control
like a drawing control or your svg control it could simply return something
that says it's a specialized control and will be dealt with by accessibility
events. There are always going to be apps like a 3D drawing kit or
something that just is not going to be easy to make accessible but for a
good portion of applications forced roles and accessible text and
descriptions would fix a lot of our problems.
Ken
-----Original Message-----
From: blindmath-bounces at nfbnet.org [mailto:blindmath-bounces at nfbnet.org] On
Behalf Of Michael Whapples
Sent: Tuesday, January 10, 2012 9:08 AM
To: Blind Math list for those interested in mathematics
Subject: Re: [Blindmath] How useful is a GUI to blind users?
Hello,
I too don't really want to drag out this thread, however what I am going to
say does certainly have its relevance to maths and other technical subjects
so I felt it was worth saying here.
While the idea of built in accessibility which developers must use may seem
appealing, I doubt it will be the final thing in making applications
accessible. The problem is custom controls. I don't mean custom controls
where the developer decides they want something that looks different to
normal, yes this is an issue but its separate to the one I want to discuss,
the problem I am on about is where a custom control really is needed because
the developer needs something with quite advanced functionality. An example
of such a custom control I am thinking of might be the control for a WYSIWYG
maths editor, the standard editor type controls really will not be enough.
Another example of a custom control, which I will use throughout this
message, could be a control for editing an SVG diagram, allowing a user to
drag shapes they want on to the drawing area, drag shapes around the drawing
area, allowing users to push elements backwards or forwards in the stack of
elements on the diagram, allow users to resize elements and allow users to
select an element and adjust properties like colour and opacity. In fact
this control may be a number of smaller controls, one for the drawing area
and one for each shape, but that sort of thing does not really matter for
this. Basically you probably can imagine such a control would not be in a
standard GUI toolkit and possibly developers would want to implement it
slightly differently and so it may not really be correct for it to be a
standard control in a toolkit. As such a control is so custom the toolkit
would not be able to provide any accessibility for such a control
automatically, only the control developer will know fully its behaviour and
what information should be exposed so they would need to use the
accessibility API to provide the information. I decided to use this SVG
editing example as its one that the standard graphical control could be made
accessible, for example the elements could be selected using the keyboard,
the accessibility API could let the screen reader know which element is
selected, elements could be dragged and resized with the keyboard with the
position or size being reported through the accessibility API, also the
accessibility API could report whether the element overlaps with another
element and what that other element is and whether the selected one is in
front or behind the other element.
Why it could not be a standard control, well may be in a given context the
fact of whether a element is in front or behind another is irrelevant, the
important fact is that they overlap and so to have the accessibility API
tell the screen reader about whether the element is in front or behind would
just end up being clutter. If it was important to know whether the elements
overlap, the reason it is important might be because elements should never
overlap and therefore the control should actually prevent you and in such a
case when you cannot move an element because it would start to overlap the
accessibility API possibly should let the screen reader know that the shape
cannot be moved because it will overlap.
Unfortunately I think to achieve manditory accessibility for these more
advanced controls is something which will never happen as its not really
possible for the toolkit to properly enforce the use. Also separately who or
what enforces that the toolkit implements accessibility, there are toolkits
like TK which I believe have no accessibility on any platform.
Michael Whapples
-----Original Message-----
From: Ken Perry
Sent: Tuesday, January 10, 2012 12:17 PM
To: jtblas at hotmail.com ; 'Blind Math list for those interested in
mathematics'
Subject: Re: [Blindmath] How useful is a GUI to blind users?
I am mainly answering your first and last statements because I think we both
agree. My opinion as a coder is that all access should be in the
development libraries. For example a control should not be allowed to work
if it doesn't have the correct accessibility fields in. For example if you
want a graphical button that only has mouse access fine but you need to have
the access roles filled in or it's a compiler error. That is the only way
we are going to end up with all applications made accessible. You might
think that programmers will just put stupid in formation in the field just
to quickly get done but that is even ok because as long as the information
is there one or two things can happen. The first being a screen reader can
make special labels so that the stupid information don't show or people can
post the software somewhere and point out the programmers intentionally did
not fill the fields in correctly. I personally believe that with as easy as
it would be to fill in some access fields most programmers would do it. The
fact that Mac programs are mostly accessible and so are .net if they don't
do unusual graphic stuff is what is making most software accessible now. If
we go that extra step and force programmers to add accessibility as part of
the language then it I think it would be shocking how fast programs would
become accessible..
So I guess what I am saying is people who make these development libraries
like swt, wxWidgets, .net coco. Need to make it more than just a suggestion
when you build your controls. It could be done. I think we should drop
this thread before it drifts farther away from math though but it's an
important topic.
Ken
-----Original Message-----
From: blindmath-bounces at nfbnet.org [mailto:blindmath-bounces at nfbnet.org] On
Behalf Of Jose Tamayo
Sent: Monday, January 09, 2012 2:23 PM
To: 'Blind Math list for those interested in mathematics'
Subject: Re: [Blindmath] How useful is a GUI to blind users?
My comments are inserted using my initials [JT] throughout the e-mail
threads:
-----Original Message-----
From: blindmath-bounces at nfbnet.org [mailto:blindmath-bounces at nfbnet.org] On
Behalf Of Ken Perry
Sent: Sunday, January 08, 2012 5:14 PM
To: 'Blind Math list for those interested in mathematics'
Subject: Re: [Blindmath] How useful is a GUI to blind users?
Actually Richard I have programmed blind as far back as MsDos 5.0 and I have
used Linux since the early days of slackware .9. It is true that question
and answer can be a good interface but It was never perfect you mentioned
the file dialog I will point at a more important one and that is the Edit
box. Prior to current GUI's you never knew what you were going to get for
an editor and even now you are not even sure. The problem is not GUI's per
say it's the problem of people not thinking of accessibility before they
code something. For example you would think that all buttons should be
accessible but the problem is some coders think they must make a circle
button using graphics only and then that button becomes inaccessible without
work of someone using a screen reader that can label that graphic button.
It gets worse when coders create a graphic out of text and while the program
runs they change that text. My wife has been known to look at my screen and
say um its right there in text you should be able to read that. Well I can
now that I can OCR the screen with NVDA or Jaws but it's still an awe full
interface.
[JT]: Frankly, it would be too cumbersome to write apps that give a slew of
prompts to end users. Especially the more complex programs / applications.
Furthermore, I don't think that all developers will ever thingk of
accessibility as one of their development goals if the primary users of the
technology are sighted users. The technology must already have the built-in
accessibility out of the box. If it is left up to the developers, then we
are still left with the question of why developers don't think of
accessibility. The providers of APIs a are the ones that must include
accessibility out of the box just as they include certain requirements for
controls and objects.
You are write that a console app is very accessible but it depends on what
you want to do you cannot really step back and make a command line editor.
If that was something people wanted to use they would still be using sed,
and Edlin. I still use sed but not for serious editing.
[JT]: Wow, edlin, I remember that one. What is being proposed is an app
that prompts the user for all requirements and then performs a task. What
we are describing is batch processing. It is inevitable that technologies
will change and we must insist of companies such as Microsoft et all that
they provide accessibility built-in out of the box. However, the evolution
will continue and this argument of accessibility will forever be present in
some form or other. The question I ask is How do I take software that is
inaccessible and make it accessible? Well, companies such as Freedom
Scientific are answering many of those questions with technology offerings
such as Screen OCR.
Another problem with making console apps is that you have to make it.
Meaning we shouldn't have to depend on special made software and windows and
Mac are both doing much better now making things more accessible. Now that
is not to say you cannot make specialized software but one thing to think of
is many of the instructors that help students with the software are sighted.
They expect to see a certain type of software and many are not willing to
learn special software for one or two students. It is always wise to make
software universally accessible so that anyone can pick it up and use it
rather than making a specialized bit of software for one type of person.
[JT]: Universally accessible anything is amouth full and I agree with you!
I just don't know how we can make something universal right now without
bringing in the argument of who makes it universal and where does funding go
for such an endeavor. I guess my question is who will be willing to openly
share ideas and come up with a system that works for all without the
almighty dollar being the driving force. Academically, it is feasible.
What group, however, is willing to openly share ideas and come up with
solutions that address the need? I don't really know because I have no
experience in any of these areas. I do know that there are smaller projects
and large projects that are working separately in Silo's where progress is
halted and information is protected by the many complexities associated with
academic work and private sector work. In other words, if a small group is
working on solving a problem, it becomes the problem of that small group to
solve it because there is private sector moneys involved or there are ideas
to protect.
Just my opinion though.
Ken
-----Original Message-----
From: blindmath-bounces at nfbnet.org [mailto:blindmath-bounces at nfbnet.org] On
Behalf Of Richard Baldwin
Sent: Saturday, January 07, 2012 12:45 PM
To: BlindMath Mailing List; accessibleimage at freelists.org
Subject: [Blindmath] How useful is a GUI to blind users?
It occurred to me the other day that prior to the advent of the Graphical
User Interface (GUI), the user interfaces for all programs were accessible
for blind users so long as they had a screen reader that would speak the
information displayed on the command-prompt screen.
[JT]: Wow, we are talking about many years past!
For those who are too young to remember, programs in that day prompted the
user for input and the user responded in a back-and-forth dialog fashion.
Once all of the input data was provided, the program ran and did whatever it
was supposed to do.
[JT]: This reminds me of the Mainframe days when COBOL and JCL were used to
generate reports based on entered information or data files stored in DASD
drives. However, we are past that era and onto a new era which we must
adapt to. There is still a place for such technologies but not in the rich
GUI interfaces that we all demand today.
Another way that information was provided to the program was in the form of
typed information (commonly called switches) provided by the user when she
started the program running. Batch files were often created with a simple
text editor to make this procedure less prone to typing errors.
The one area where I see the GUI being particularly useful for a blind user
is the file selection dialog. The use of the GUI dialog eliminates the
requirement to type long path and file names. However, if the disk is
organized in such a way as to keep the paths short, even this doesn't appear
to be a significant advantage.
[JT]: There are many other advantages of using a GUI. For example, before
the creation of Long File names, we were forced to use 8 or 11 characters
for filenames (in the PC world). When long file names were introduced
because we needed friendly names to remind us of content within files and
folders (called directories in the past), we all became much more productive
because we no longer had to keep reference index files to ttell us what our
files had in them. We could name our files and directories (called folders
today) and we would know what the files contained. Of course, there
are other benefits to Graphical User interfaces for all.
For those who don't know, and without getting into the technical details as
to why, there are major problems associated with creating accessible user
interfaces when programming in Java. Using the SWT to create accessible user
interfaces significantly reduces the power of the Java programming
environment because it precludes the use of many excellent programming
libraries.
[JT]: when Java was first invented by James Gosling, we were concerned with
the performance of the JAVA environment because it was slow and the PCs of
the time simply were not able to interpret JAVA fast enough. Java was
built to be portable and hence its portability generated many headaches for
PC vendors. The promise of portability made JAVA very elegant. And JAVA
became ubiquitous. Now we must learn to make those libraries that are not
accessible available to everyone. In due time, we will make it all work.
I suspect that more libraries will be developed with such challenges and
many other challenges. Accessibility is another challenge that we have to
work to make better.
This causes me to wonder if, for those programs that are primarily intended
for use by blind and VI users, it might make sense to go backwards in time,
forego the GUI, and write those programs using the "old-fashioned" prompt
and reply style of user interface. I would be interested in seeing some
discussion on this topic.
[JT]: while this sounds intriguing, we cannot go backwards. We must move
forward with an effort to make the technology accessible. Perhaps there is
a an area of industry in which this is viable. However, we are making leaps
forward and I think we should use the past to learn to make future
technologies better.
Dick Baldwin
--
Richard G. Baldwin (Dick Baldwin)
Home of Baldwin's on-line Java Tutorials http://www.DickBaldwin.com
Professor of Computer Information Technology Austin Community College
(512) 223-4758
mailto:Baldwin at DickBaldwin.com
http://www.austincc.edu/baldwin/
_______________________________________________
Blindmath mailing list
Blindmath at nfbnet.org
http://nfbnet.org/mailman/listinfo/blindmath_nfbnet.org
To unsubscribe, change your list options or get your account info for
Blindmath:
http://nfbnet.org/mailman/options/blindmath_nfbnet.org/kperry%40blinksoft.co
m
_______________________________________________
Blindmath mailing list
Blindmath at nfbnet.org
http://nfbnet.org/mailman/listinfo/blindmath_nfbnet.org
To unsubscribe, change your list options or get your account info for
Blindmath:
http://nfbnet.org/mailman/options/blindmath_nfbnet.org/jtblas%40hotmail.com
_______________________________________________
Blindmath mailing list
Blindmath at nfbnet.org
http://nfbnet.org/mailman/listinfo/blindmath_nfbnet.org
To unsubscribe, change your list options or get your account info for
Blindmath:
http://nfbnet.org/mailman/options/blindmath_nfbnet.org/kperry%40blinksoft.co
m
_______________________________________________
Blindmath mailing list
Blindmath at nfbnet.org
http://nfbnet.org/mailman/listinfo/blindmath_nfbnet.org
To unsubscribe, change your list options or get your account info for
Blindmath:
http://nfbnet.org/mailman/options/blindmath_nfbnet.org/mwhapples%40aim.com
_______________________________________________
Blindmath mailing list
Blindmath at nfbnet.org
http://nfbnet.org/mailman/listinfo/blindmath_nfbnet.org
To unsubscribe, change your list options or get your account info for
Blindmath:
http://nfbnet.org/mailman/options/blindmath_nfbnet.org/kperry%40blinksoft.co
m
More information about the BlindMath
mailing list