Re: Making a crossword grid accessible
Re: Making a crossword grid accessible
- Subject: Re: Making a crossword grid accessible
- From: Travis Siegel <email@hidden>
- Date: Mon, 15 Dec 2008 17:43:22 -0600
One thing to point out here.
You don't need to tell your app to make vo speak when the person types
a character (to echo the character I mean) vo will do this or not,
based on their preferences.
As for your layout design, I see nothing wrong with your table
approach, and honestly, it's probably the best design you could do,
since there's nothing similar in the accessibility framework (that
I've seen)
I use voice over every day, and I can tell you, once folks get used to
how your table is laid out, it won't be a problem.
Try not to offer too much feedback, as this is almost as irritating as
not enough feedback.
Perhaps, what you could do is add keystrokes that will read particular
pieces of text.
I.E. command-r to read the row, command-c to read the column, command-
s to read a summary of the found/notfound words, and so on.
A crossword app would be just the thing, if you need another tester,
let me know.
On Dec 15, 2008, at 3:58 PM, Daniel Jalkut wrote:
Hello all, I'm writing for the first time, after recently diving
into what is turning out to be a challenging accessibility exercise.
I would appreciate any experienced developers or designers giving me
some advice on how I could best achieve accessibility in this
situation.
I am the developer of Black Ink, an application for downloading and
solving crossword puzzles on the Mac. It was brought to my
attention that the application is almost completely inaccessible,
due largely to the fact that the crossword solving "grid" is a
custom view which doesn't currently expose any UIElements.
I am planning to "test" the results of this work with a blind user
who has asked for the functionality, so these assumptions are by no
means set in stone, but I think some behaviors include:
1. When a square on the puzzle is first selected, the associated
clue is announced, along with the currently entered answer letters
for that that word, and the cursor position within that word. For
instance, when the user selects the first word in this puzzle:
http://www.red-sweater.com/snips/AccessibleXword-20081215-154434.png
I believe VoiceOver should announce something along the lines of:
"one across, crack and redden, four letters, first letter selected,
existing answers blank, H, blank, P."
2. As the user enters answer letters, VoiceOver should announce the
typed letter.
3. As the selection within a word changes, VoiceOver should simply
announce the new position within the word. E.g. if the user presses
the right arrow key from the state in the image above, I would hope
for something like "second letter selected, existing answer H".
At first I decided to implement the UI element as a "table" role,
seeing as how the crossword is comprised of a grid structure and has
rows and columns. But I believe this is something of an
implementation detail for sighted users, and not particular
effective for conveying the structure of a puzzle to e.g. a blind
user.
The way I'm thinking of it now is that the puzzle grid is a group,
that contains "Word" UIElements which are of a text field role. But
even with this approach, getting the kind of VoiceOver effect I'm
hoping for seems to be difficult or impossible.
I've found in the archives evidence that it might be impossible to
get VoiceOver to notice value changes in "Faux" UI elements.
Currently, the puzzle view is a true subclass of NSView, but all of
my interior constructs for accessibility are faux UI elements.
Does anybody have opinions on how I should pursue this? Do you think
I should stick with the "group comprised of words" approach, or
should I go back to a strictly grid-oriented representation? Given
the specific types of puzzle-solving feedback I want to convey to
users, I'm beginning to think that it will be impossible without
hacking/abusing some existing role to achieve the ends. For
instance, I could imagine having my NSView fulfill the "text area"
role and, in order to get certain audio feedback to the user, having
their navigation of my UI fake certain manipulations of text. Of
course, this feels like it would be a means to an end for VoiceOver
in particular, and may be at the expense of general accessibility
for other purposes.
Appreciate any thoughts on this. I realize it's sort of a long-
winded inquiry, but I hope that somebody who is fascinated by this
kind of problem will find it worth digging into :)
Daniel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (Accessibility-
email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden