[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Voting & Accessibility
I have also been looking into accessibility issues. I have never seen a
decent analysis of how accessibility issues impact voting system design, so
I've been gradually putting one together. After that, the next step is to
see how the design of an XML specification for voting could/should be
impacted. My analysis is not complete, but I'm attaching my notes below as
a sort of status update - to give visibility into what I'm looking at. As
can be seen, the notes are in a very rough, developmental state. I will
send out the final version of this when I complete it. If anyone cares to
comment on any of this to me directly or to the list, please feel free to.
Best Regards,
Thom
----------
Involves bi-directional human/voting-device communication.
Voting Disability = any physical, mental, or communications obstacle which
can hinder a person from successfully casting their ballot in an accurate,
private, and secure manner.
Voting Accessibility = insuring that all people have equal opportunity to
cast their ballot in an accurate, private, and secure manner.
-----------------
Output Data
-----------------
- text
- binary graphic
- binary audio
- Braille specific (blind/deaf user interface navigation)
- vibration/pulse control (blind/deaf user interface navigation)
- resistive force control (blind/deaf user interface navigation)
----------------------
Output Methods
----------------------
- visual
- audio
- tactile
------------------------------------
Output Method Translation
------------------------------------
- text --> graphic
- text --> audio
- text --> tactile
- text --> user interface attributes/definition
------------------------
Output Capability
------------------------
- Default Output Data = Text
- Allow for …
- outside files (graphic files, audio files, any file type) to be used
in place of, or in addition to, text data
- special-purpose text fields/elements (defined by each implementer)
to be used as part of the output.
- Note … Don't require that "text" data be available. Allow implementers to
determine what type of output data they'll use. Any given application or
implementation may have it's own way of being accessible using
special-purpose or proprietary file types and interfaces.
---------------
Input Data
---------------
- conversational (natural language) [ … add to items below … ]
- text (ASCII, Unicode)
- numeric (0 through 9, decimal points, positive, negative)
- pointer (x-y coordinates)
- arrow (left, right, up, down) [ … add to items below … ]
- scroll (up, down)
- tab (forward, backward)
- click (focus on, select, custom functionality)
--------------------
Input Methods
--------------------
- voice
- keyboard
- keypad (telephone)
- pointing device (mouse, trackball, touch pad, touch screen)
- arrow keys
- mouse wheel (for scrolling)
- tab keys
- mouse button (or some other type of on/off switch)
--------------------------------
User Interface Methods
--------------------------------
Voting system user interfaces are designed with specific input devices in
mind. However, with accessibility, some voters will not be able to use the
default user input device for a voting system. Because of this, data from
whatever input device a voter is able to use would need to be translated so
that it appears to the voting system to be an input device which the user
interface was designed for.
For example, a quadriplegic voter would not be able to use a touch-screen
but may be able to use voice commands to vote. In this case, the voice
commands would need to be translated so they would appear to the system to
be someone touching the touch-screen.
A more extreme example would be a quadriplegic voter who, for whatever
reason, would only be able to use a "twitch-switch" for user input. A
twitch-switch is a small device placed on a person's skin that is activated
by twitching or contracting the muscle directly beneath it. My
understanding is that profoundly disabled individuals use these switches.
If this is the only way a voter can communicate with the voting system,
then the user interface would need to use the simple "on" and "off" states
of the twitch-switch in a way that allows the voter to perform all
navigation, selection, and data entry functions.
** Planar **
Planar user-interfaces display many elements on a single "plane" which can
be considered at one time, in any order the voter chooses. Planar
interfaces would normally be visual in nature. Examples of planar
user-interfaces would be a touch-screen voting system or a full-face ballot
touch system (which uses a large paper ballot with electro-mechanical
switches underneath the paper for voters to press, along with small lights
which indicate the voters choices).
- planar --> voice …
- planar --> keyboard …
- planar --> keypad …
- planar --> pointing device …
- planar --> arrow keys …
- planar --> mouse wheel …
- planar --> tab keys …
- planar --> mouse button …
** Linear **
… allow only one element to be considered at one time and generally only
two directions to traverse through the ballot elements and ballot pages …
- linear --> voice …
- linear --> keyboard …
- linear --> keypad …
- linear --> pointing device …
- linear --> arrow keys …
- linear --> mouse wheel …
- linear --> tab keys …
** Binary **
… consists of only a single on/off switch to convey all user input …
- binary --> voice …
- binary --> keyboard …
- binary --> keypad …
- binary --> pointing device …
- binary --> arrow keys …
- binary --> mouse wheel …
- binary --> tab keys …
-----------------
Input Types
-----------------
- navigation (pointer, scroll, tab)
- selection (click)
- data entry (text)
---------------------------------------------
Device-to-Human Communication
---------------------------------------------
** Sense of Sight **
- Device Output = visual
- Output Data = text or binary graphic
- Devices = monitor screen, display glasses
- Monitor screen = widely used
- Display glasses =
- eShades by InViso (http://www.inviso.com/eshades.html)
- MicroOptical (http://www.microopticalcorp.com/)
** Sense of Hearing **
- Device Output = audio
- Output Data = text or binary audio
- Devices = speakers, headphones, telephone
- Speakers = widely used
- Headphones = widely used
- Telephone = widely used
** Sense of Touch **
- Device Output = tactile
- Output Data = text only
- Devices = Braille readers
- Braille readers = Blazie (http://www.blazie.com/pages/hardware.html)
** Sense of Taste **
- not applicable
** Sense of Smell **
- not applicable
----------------------------------------------
Human-to-Device Communication
----------------------------------------------
** Hand/Finger Movement **
- Device Input = hand-movement
- Input Data = text, pointer, scroll, tab, click
- Devices = touch screen, trackball, mouse, keyboard, keypad
- Touch screen =
- Elo Touch Systems (http://www.elotouch.com/)
- Touchscreens.com (http://www.touchscreens.com/)
- Trackball =
- Kensington (http://www.kensington.com/products/pro_c1018.html)
- Mouse = widely used
- Keyboard = widely used
- Telephone keypad = widely used
** Speech **
- Device Input = voice
- Input Data = text, scroll, tab, click
- Devices = speech-recognition, VoiceXML
- Speech-recognition =
- Lernout & Hauspie (http://www.lhsl.com/naturallyspeaking/)
- IBM (http://www-4.ibm.com/software/speech/)
- VoiceXML =
- VoiceXML Forum (http://www.voicexml.org/)
** Head Movement **
- Device Input = head-movement
- Input Data = pointer, click
- Devices = head switch, head-mounted pointer
- Head switch =
- Technical Solutions
Australia (http://www.tecsol.com.au/SwitchVarious.htm#Head Switch)
- Head-mounted pointer =
- Tracer by Boost Technology
(http://www.boosttechnology.com/tracer_description.html)
- TrackIR by Natural Point
(http://www.naturalpoint.com/prod/at_product.htm)
** Eye Movement **
- Device Input = eye-movement
- Input Data = pointer, click
- Devices = eye tracking
- Eye-tracking =
- EyeGaze by LC Technologies (http://eyegaze.com/doc/ecs.htm)
** Special Switches **
- Device Input = various
- Input Data = click, scroll, tab
- Devices = twitch switch, sip/puff switch, tilt switch, etc.
- Special Switches =
- Technical Solutions Australia
(http://www.tecsol.com.au/SwitchList.htm)
---------------------------------------------------
Obstacles & Communication Methods
---------------------------------------------------
** Deaf **
- Explanation = deaf or hard of hearing
- Output = visual or tactile
- Input = hand-movement, head-movement, eye-movement
- Comments = none
** Blind **
- Explanation = blind or vision impaired
- Output = audio or tactile
- Input = hand-movement, audio, head-movement, eye-movement
- Comments = none
** Quadriplegic **
- Explanation = unable to move
- Output = visual or audio
- Input = audio or eye-movement
- Comments = none
** Muscle-control **
- Explanation = difficulties with muscle control
- Output = visual or audio
- Input = audio or special switch
- Comments = none
** Cognitive **
- Explanation = difficulty with comprehension
- Output = any
- Input = any
- Comments = uses pictures of candidates & extra explanatory comments
guiding the process (the extra-comments-mode would automatically kick-in if
a voter is taking abnormally long or seems confused based on their
navigation patterns). may also want to enable an extra-help-mode along with
the extra-comments-mode. extra-help-mode would allow user to open up a list
of context-sensitive questions, select a question, and be guided through
the process.
** Mobility **
- Explanation = traveling to a polling place is difficult or impossible
- Output = any
- Input = any
- Comments = would need mobile voting appliances, such as a webpad device,
that could allow curbside voting - or could be taken to nursing homes,
hospitals, ships, submarines, etc. would need to allow for mobile voting
machines which are unattached from the rest of the voting system. perhaps a
synchronizing mechanism when the mobile unit is reconnected with the rest
of the system. also may want to allow for wireless voting, over a cellular
network. Wireless Application Protocol (http://www.wapforum.org/), DoMoCo's
I-mode (http://www.nttdocomo.com/i/), and Sun's Java2 Micro Edition
(http://java.sun.com/j2me/) are all possible ways to implement wireless
voting.
** Dexterity **
- Explanation = difficulty in handling or controlling small objects, such
as a stylus, mouse, or track-ball
- Output = any
- Input = any
- Comments = need to minimize the need to deal with small or difficult to
maneuver objects.
** Illiteracy **
- Explanation = unable to read
- Output = any
- Input = any
- Comments = use pictures of candidates & graphic logos for each party for
each contest involving people running for office & the narrator reading the
names of each candidate as they are highlighted or selected. for proposals,
referenda, etc - for "no" use a read stop sign, or a thumbs-down graphic,
or a stop light with the red light highlighted, or a white circle with a
red border, the word "NO" inside it, and a red line going through the word
diagonally. for "yes" use a green circle with the work "GO" or "OK" in it,
or a stop light with the green circle highlighted, or a thumbs-up graphic.
** Speech **
- Explanation = difficulty with speaking, speech impediment or mute
- Output = any
- Input = hand-movement, head-movement, eye-movement
- Comments = speech impediments can make it difficult for voters to ask
questions of poll workers. Having all polling place instructions written
out and clearly visible helps prevent the need for voters to ask questions.
For remote or Internet voting systems, if a dial-up phone number is
provided for assistance it would be best to provide some way to get
assistance without a person using their voice (i.e. Internet chat
application connecting voter to help desk).
** Language **
- Explanation = ballot content not available in the voter's native language
- Output = any
- Input = any
- Comments = for foreign language speakers, use language-customized
versions of the system. for those voters who don't speak any of the
languages offered, use the same techniques as for illiterate voters.
** Learning **
- Explanation = difficulty with reading, dyslexia, attention deficit
disorder, or other learning disability
- Output = any
- Input = any
- Comments = using multiple modes of output to the voter would be helpful.
voters with a learning disability could be assisted in ways similar to how
voters with illiteracy or language challenges are assisted.
----------
So, given this information, what needs to be done to make a voting system
accessible to all voters?
----------
How does this relate to creating a voting-specific XML specification? What
impact does it have, or should it have, on the specification?
----------
-tgw
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC