Re: Accessibility Issues with NSPopover (MacOS)
Re: Accessibility Issues with NSPopover (MacOS)
- Subject: Re: Accessibility Issues with NSPopover (MacOS)
- From: Motti Shneor <email@hidden>
- Date: Sun, 27 May 2012 09:20:37 +0300
On 25 במאי 2012, at 20:11, email@hidden wrote:
Hello Travis, and thanks a lot for taking the time to write these enlightening lines. However, I still find some of your assumptions unclear, especially regarding my own special situation, so I introduce a few more clarification questions inside your text. I'll be more than happy to read your response.
> From: Travis Siegel <email@hidden>
> To: Motti Shneor <email@hidden>
> Cc: email@hidden
> When a new window shows up, vo does announce the window, though it's
> not always obvious what the window refers to, or indeed if it's a new
> one, or a reinit of an existing one, because vo usually only says
> something like "New Window" or something similar. However, as I've
> mentioned on this list before, and to several developers, and what I
> strongly urge developers to keep in mind, is that vo users don't want
> you (as the developer) to "tell" them what they should be looking
> at.
But what about new information, NOT IN A NEW WINDOW that might be important? (example, you're collaborating with other people in some chat program, then the host decides to assign to you some more abilities (for instance, to administer the virtual room). No new window is created, no alert dialog is presented because it would distract normal course of things --- but the change must be communicated to the user. Usually there's a "status line" or some other predefined place where important network-born messages are presented, in a way that is highly attractive to the user's eye.
I agree that accessibility user should have the same experience, and he must NOT be automatically focused on the message line, but still --- How in the world will he ever know of this change (displayed for only few seconds to a regular user) if VO won't announce it somehow?
> It's a screen reader's job to read the screen, nothing less,
> nothing more. Any added features are a nice to have, but doesn't
> mean they should be used in all cases. Knowing there's a screen with
> the info I need is generally enough, I don't (usually) wish to be
> yanked out of what I'm currently doing, and be dumped into anther
> screen, just because the author of that particular program thought I
> needed to know what it says, and I need to know right now.
> I can't tell you how extremely irritated I used to get when safari
> was chugging along loading a web page, and I went to check mail, then
> when the page was done, voiceover would happily switch me (focus and
> all) to the safari page that had just loaded. It didn't matter if I
> was in the middle of typing a message, viewing subject lines, or
> pressing enter to read the message in the cursor, safari would grab
> the control, and all my input would then be directed to safari
> instead of mail. Of course, as soon as apple added the checkbox to
> move to newly loaded web page, you can be sure I unchecked that box
> just as fast as I could find the silly thing, and I've never regreted
> my choice.
Somehow, I consider my case just the opposite. Flow is this:
As a user of the application, you press a button on the toolbar, that opens a little PopOver, in which you can see how information is gathered from OTHER USERS of the application on the net. It's like some kind of questionnaire being answered and summarized over time.
But then --- something happens, and the main-window of the application displays an alert-sheet (error message, or some other user's question, etc.). Here it is MacOS who steals the focus from the PopOver you intentionally created and focused on, and was in the middle of reading of. It is MacOS who "drags you by the hand" here.
I complained that here a blind user is kind'a lost. There is no easy way for him to dismiss that alert, then somehow return to the NSPopOver, (except for the VO-F2-F2). I wished there would be some sensible link between the toolbar-icon to which the NSPopOver is anchored, and the NSPopOver itself. Isn't this reasonable, and even preferable?
> If you need to play a tone of some sort to let people know the info
> is present, then do so, but don't ever take control of the user's
> session, and force them into something they won't know they're in, it
> only creats illwill, and (in extreme cases) turns off the user, and
> they won't use that application, no matter how accessible it may be.
Oh yes, please, TELL ME HOW. I could not find any API to just announce a message to the user in an accessible way, WITHOUT changing either the application keyboard-focus, or VoiceOver focus.
> There's such a thing as being too helpful. I don't like when folks
> grab my arm and begin dragging me across the street at an
> intersection, and I sure don't like when software tells me what I
> should be looking at instead of allowing me to make the decision for
> myself.
Point taken and accepted --- still
> I realize you're trying to help, and letting folks know there's
> something that needs looked at is important, but jerking them out of
> whatever they're doing, and slamming them into that particular screen
> just because *you* think it's important isn't the way to do it.
Are you willing to agree that there are exceptions? In my application, for instance, you sometimes get thrown from the "chat" or "meeting room", by the host, or by the server, or because of a network error. In such cases, even as a regular user, focus IS CHANGED FOR YOU. Can you propose any better design for such cases?
> If
> you don't make the whole screen a window, and cover up everything
> else on the monitor to force sighted folks to look at your screen,
> then you shouldn't force vo users to be preempted from their work to
> do the same.
> Think about your design, and try to come up with something that will
> allow the users to know info is there, and perhaps make it a point in
> the documentation to explain such screens, but for everyone's sanity,
> please don't *8force* them to look at things just because you think
> it's important, the user in question may not think so, and it's a lot
> easier to explain a lost screen than it is to explain you interrupted
> their other work, because you *wanted* them to see your progress
> update. Remember, this isn't dos, folks can and do multitask, and if
> your program isn't foremost, then there's no need to coopt their
> attention to dealing with that program unless something drastic has
> taken place, but in that case, I think other cues would already tell
> the user there's trouble. :)
> I hate to keep harping on this, since every developer has (what they
> believe to be) good reasons why they *should* force the user to look
> at this or that, but remember, the user should be in control of what
> they do, and if that means they don't get to see a screen the instant
> it pops up, then that's the tradeoff you need to accept to allow them
> to use their machine the way they want to use it.
> Making the screen accessible with the command-~ key should be enough,
> if you can do that, and there's no need for the user to resort to vo-
> f2-f2, then everything should work as expected, but even with apple,
> sometimes a vo-f2-f2 is necessary (finder pop-ups do this sometimes,
> as do javascript pop-ups on web pages depending on how they're coded)
> so at least an experienced vo user will know to look in the vo-f2-f2
> area if they can't find something they're looking for, but this still
> isn't a reason to force the issue programatically.
>
All I wanted is to provide a LINK so that VO user can ELECT to follow that link.
The only place where I wanted to programmatically change accessibility-focus, was to RESTORE FOCUS that was stolen by OS (displaying an alert-sheet over another window) when that alert is dismissed. Is this so bad?
> Vo users are always grateful to developers who take the time to make
> their programs accessible, and I'm not in the least trying to
> undermine that here, I'm only urging developers to seriously think
> about their approach to that accessibility, and consider how usable
> that solution may be. In short, if you don't enforce sighted users
> to do particular things then you really shouldn't try to force vo
> users to do those things either.
But I DO stress information onto sighted users on important new information, via always-visible status-message box, bright colors on text, and other typographic means to draw user's attention to the message. The only difference is, that a sighted user is not distracted from his original focus, because he can see both things simultaneously. I'd want to allow accessibility users to have the same experience.
> I'm getting long winded here, and that's not my intent, I'm only
> trying to explain how I myself view such things, and other vo users
> I've talked to (generally) agree, though there's always those who
> disagree with me, and that's fine, since that's the whole point of
> choice right?
> The point is, we always love when a program is accessible, and on
> osx, that's a *much* larger out of the box percentage than on other
> operating systems, but just because apple provides tools, it's not
> necessary to force those tools on the end users. Having a program
> that's not quite accessible (I.E. unlabeled buttons and areas of the
> screen that have no decernable purpose are annoying too, because they
> frustrate us knowing the program *can* be used, only if ...
> But those that try too hard are frustrating too.
OK.... we won't :)
> Whether or not that applies in this case isn't up to me to decide,
> I've not used the program, so can't comment on that directly, but I
> do know that when a program forces me to do something, even if it's
> beneficial to have it done may not be what I wanted at that
> particular moment, and so can be just as frustrating.
> Overall, I think developers do a decent job, but I'm constantly
> seeing requests on here asking how to force vo to do this, or how to
> force vo to do that, and I just want to remind developers that vo
> users are still users, and should be treated as such. Some are
> advanced, and some are beginners just like everyone else, which may
> make for a little more support work (explaining the screen is there)
> but that doesn't mean they're any less capable of doing what needs
> done, please, folks, keep in mind when developing accessible programs
> that it is possible to be too helpful, and forcing vo to go here or
> there (imo) falls into that too helpful category.
> I think I've gotten away from my original point, and this probably
> isn't the best way to explain it, but I hope folks understand, and
> take this note the way it was intended, simply as a reminder, or
> gentle guidance, nothing more.
>
Point taken --- thanks again.
Motti Shneor, Mac OS X Software Architect & Team Leader
Spectrum Reflections Ltd.
+972-54-3136621
_______________________________________________
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