What is the best approach to make an SPA (AngularJS) Accessible (for screen readers etc)?
I have little to no experience with the aria specification, and I wonder if it will at all work on a single page application.
What are the common pitfalls when developing?
How do one debug and test the accessibility when developing?
This could cover a broad swath of issues here. So I'll go through some of the basics in the hopes that it starts you on your way, the common pitfalls, as it were.
Firstly, like the commenters said, yes, you need to make sure ARIA tags are employed correctly. So, say, if you wanted to expose a div as a button, you'd have something like this.
<div id="mysuperflashybutton" ... role="button" aria-label="Super flashy" tabindex="0"></div>
This button when selected by a screen reader will be called "super flashy button", so you don't need to put button in your aria-label attribute. There are more complex examples out there, but that illustrates the basics of it, pretty much. Role, aria-label and tabindex will be the most prevalent ARIA attributes you see.
Tab-indexing elements that you want screen reader users to click on is vital to this. Set tabindex to 0 to include it in its default location on the document. If you don't want it to necessarily normally be reached by people using keyboard navigation, set it to -1. This means it's out of the normal tab order, but can still be navigated to if you want to put the user's focus there manually through javascript/jquery .focus().
As mentioned, sometimes you can assist keyboard navigators/screen reader users by moving their focus for them. An example would be if they click a button and a menu appears. You could do something like this to put them on the first link of the menu:
$('#linkmenuactivator').on("click", function () {
$('#linkmenu').find('li:first a').focus();
});
I know that's in JQuery, I'm not familiar with AngularJS but my brief view makes me think it's more of a ViewModel controller as opposed to something UI specific like JQuery, but correct me if I'm wrong.
Live regions can be used if you're doing funky things on screen that will make no sense to a screen reader user. You can write text to the elements in these regions to put the information out textually. The easiest way to do this is to use a role of alert or status, for important messages or generic status updates respectively. These roles make your element a live region by default, and any text changes in there will be reported to the screen reader. So a quick example would look something like this:
<p id="ariastatusbox" ... role="status"></p>
Then later in JQuery (taking the example of you loading a document and fading it in when you've got it):
$('#maincontent').fadeIn(function () {
$('#ariastatusbox').text('Document loaded');
});
This will let the screen reader know that the document is loaded and ready to be read on screen. Live regions can be slightly tricky, but they're a powerful beasty if you can master them.
Finally, as to accessibility testing, there's a few options. Something I recently stumbled across is Wave which appears to be an online testing tool. It looks good from a first glance, you could give it a try. Another option is to grab a screen reader yourself and give it a go. I recommend NVDA which is an open-source (so therefore free) screen reader. It's my screen reader of choice and is pretty damn good. The synthesiser it comes bundled with doesn't have the nicest voice, but there are other options, or you could turn off the speech output and view a textual display of what it would be saying using the Speech Viewer. A final option is to ask for accessibility testers to take your app for a test drive. For consumer products or things in those brackets, blind people and other users of accessible tech may well volunteer to do it if asked. For more business oriented apps that you might not want out in a public forum, there are several organisations that can consult on issues of making web applications accessible.
This is by no means a comprehensive manual on accessibility, I was hoping to really kickstart you in the right direction. For a bit of a deeper look, try looking at the ARIA roles documentation (all of it will help but the code is under the definitions heading), and on from that the ARIA States and Properties documentation. They both can be a little dry, but also have the full list of everything you can use ARIA wise. Google should be able to yield some tutorials, too, I hope.
I hope this helps get you started. Good luck!
Related
Well ... at the risk of sounding like I really don't know anything about programming, I have a question about controls in Silverlight 5.
I have an OOB App that I am working with, but I need to add the User Menus (File, Edit, etc.) that are normally seen at the top of all apps. There used to be a control in VS (the Menu control) that was easily configurable. What is the control used to create the User Menus in Silverlight 5? The Context Menu is not what I am asking about. That is the right mouse click menu ... so that's not the answer ...
Please, understand my problem. It's been since Silverlight 2 since I worked in Silverlight. I appreciate any information you kind folks would be willing to provide.
There is no such thing available directly from Microsoft (meaning it's neither built-in or present in the Silverlight Toolkit).
You will have to use third-party controls such as DevExpress or Telerik.
EDIT: Some more advice in response to your comment.
Another possibility is to create UIs from scratch. There are two forms of UIs that I found inspiring lately, both of which don't use any ribbons or drop-down menues at all. The first is to use "Windows 8"-like dashboards instead of traditional menues, the other is the Windows Azure Management Portal (a web application).
I don't use traditional UI frameworks for menues myself, but mostly because I don't like those approaches and I'm picky with how user interfaces should work and look like.
But obviously you have to make a serious time investment to go new ways. And it will heavily depend on your application what approach makes sense.
Here's one simple approach that could work in a number of cases, I used it for a database application (I call it the Windows-Phone-7/8 approach):
The screen is divided into the "page" area and information bars. The information bars contain no menues, just who's logged on, a back-button, a home-button, and context-sensitive buttons depending on what's in the view. So basically it behaves like a web browser and you navigate through the app by clicking on "links" (buttons that take you elsewhere).
There's only one page area, so no windows and no popups. I've gone to the extreme of making even dialog windows to be pages.
Now you need menues. You do that with "dashboards", ie. pages that present some overview stuff and buttons that lead to the other areas of your application.
Although you could have action buttons like save or delete on the page itself, I put them in the bottom bar (but they are still dependent on the page your on) - that is exactly how it works in Windows Phone 7/8.
One last advice: The real effort is usually not in the menus anyway. Beside your application logic itself, it's a lot of little things like login screen, error handling and how to present error messages (look at the windows azure management portal for how they did that really nicely) and gracefully failing on session timeout. There's also a lot of nuisance on how you manage your data (ria-services, etc.).
So as long as you don't need fancy data grid grouping, rich-text edit or excel-like pivot controls, a toolkit might not help you as much as you'd hope - because they give you only the controls, not the entire UI.
I'm asking this because I'm in the process of writing two such editors for my Mega Man engine, one a tileset editor, and another a level editor.
When I say document editor, I mean the superset application type for things like image editors and text editors. All of these share things like toolbars, menu options, and in the case of image editors, and my apps, tool panes. We all know there's tons of advice out there for interface design in these apps, but I'm wondering about programming advice.
Specifically, I'm doubting my code designs with the following things:
Many menu options toggle various behaviors. What's the proper way to reliably tie the checked state of the option with the status of the behavior? Sometimes it's more complicated, like options being disabled when there's no document loaded.
More and more consensus seems to be against using MDI, but how should I control tool panes? For example, I can't figure out how to get the panels to minimize and maximize along with the main window, like Photoshop does.
When tool panels are responsible for a particular part of the document, who actually owns that thing? The main window, or the panel class?
How do you do communication between the tool panels and the main window? Currently mine is all event based but it seems like there could be a better way.
This seems to be a common class of gui application, but I've never seen specific pointers on code design for them. Could you please offer whatever advice or experience you have for writing them?
I guess your "panels" are Windows.Forms.Form's:
If you set their Owner to your main window, they'll automatically minimize when your main window does.
I've been dabbling in WPF for a couple of months now and I've managed to grasp most of what's about and why/when it's used but I'm still struggling to see the value of the PageFunction class.
Can someone give me a simple, but concrete example of when a PageFunction might be the correct tool for the job?
Mainly, it seems to be a pattern to formalize branching in task based UI.
Let's say you have a form with a checkmark for an optional feature, but this feature requires additional information which is too complicated to fit on the same page.
Using this pattern allows delegating information collection to another component.
Moreover, there is kind of a strategy pattern applied, since you could have various subsystems able to collect the same information, all of them inheriting the PageFunction(of T), so that the code actually calling those does not need to know any detail about it.
Those are just some ideas, I have not exactly looked into it.
PageFunction in a page = Dialog box in desktop application (without Page).
You can use a PageFunction every time you use a dialog box in a desktop application and that you want to develop a webnavigation-like behavior to your program.
The main thing page functions enable is implementing workflows with sub-tasks and managing the return stack.
If you just rely on page-to-page navigation, it's hard to pause the current navigation path, do something else, and then come back and continue. PageFunctions enable that through the concept of Returning and unwinding the navigation stack.
I provided some real world examples of this here: http://www.paulstovell.com/wpf-navigation
I have a winforms application that doesn't have a shared set of tools that I can provide on a toolbar. But I want to have a toolbar, so I was planning on using that space to provide quick links to the most popular portions of the product. I will eventually add knowledge to the product to know which screens the current user favors and provide those as quick links on the toolbar. But is this a reasonable use of a toolbar for a desktop product, from a design and usability point of view?
Do not automatically add knowledge about what a user prefers to generate a toolbar. Having a dynamically generated toolbar is confusing for users. It's fine if your configuration bar makes suggestions dynamically (i.e. suggesting buttons), but changing the layout itself is evil.
I think a toolbar makes a good aesthetic, but if you merely want to seperate parts of the app then a Tab bar makes more sense for usability.
With the advent of tabbed browsing, every user understands the tab concept.
Sure. Firefox has something similar in their 'Bookmarks Toolbar'.
Peachtree Accounting also has a toolbar like this, as do many others.
Tabbing is OK as long as there aren't too many.
Would be real good if the user could personalize the toolbar themselves. Sometimes I don't only want places I frequent, but screens that I use occasionally that are hard to find through menus or whatnot.
To me, this looks like a job for a menu with a MRU list, or support 'Add to Favorites'.
A while ago I created a drag-over check box list which allows you to check many check boxes in a single gesture. Do you think it is viable and usable on the web where people might not know how to use it. The default behaviour still works for the individual check boxes.
1 - The idea
The idea is nice and can probably be used in professional applications where you have direct contact with users and can explain them how things work, but not necessarily on public websites where users don't want to RTFM and are just looking for familiar behaviours. Unless it was just a sample exercise or a control meant to be included it in a control pack, it violates the YAGNI principle ;)
2 - The implementation
You certainly noticed that the implementation is buggy (at least on IE7 and FF3.1B2). Sometimes, a gesture above all checkboxes will select all of them but one or two. Moving the mouse over the div's above or below the list will stop the drag (I know it's a "feature", but it's not very user friendly). I Checked the source code and to be honnest, while it looks pretty neat, I just didn't want to deal with it because it is plain javascript. Don't you know that...
3 - Possible improvements
...you can write less and do more with a javascript library, typically jQuery. I would completely rewrite this control as a jQuery plugin. It will provide you with a lot of tools to make your code much easier to write, maintain and extend. Just try it, you'll love it. This is from a technical point of view. From a user point of view, try to make you control as familiar as possible, like what Angela suggested, windows explorer : a nice selection rectangle, the ability to use shit + click, or something like that. Finally, remember that for many windows checklistbox users, "selected" and "checked" are two different things.
The demo definitely needs a few enhancements to make it even a little bit useful (although I am not sure if it would be enough):
Allow the dragging to start somewhere that is not a check box.
Allow selection by dragging over the labels as well.
This problem seems similar to the action of selecting multiple files in a file explorer like Windows Explorer. Maybe it can work like the action of selecting multiple files by dragging a rectangle shape around the items to be selected (select one corner, drag to the other corner)? This has the advantage of being similar to an interface element that people may already be familiar with.
For some reason I can't open your link (it says my ip address was blocked). But I think what you're looking for is what I already did in jquery, I uploaded a plugin which I basically ported from crossbrowser.com's dragcheck functionality, it was to be found at http://plugins.jquery.com/project/dragCheck but currently the jquery plugin site is being revamped and my plugin has disappeared. I'm trying to see if they're going to put it back up or if I have to create a new project again...
Anyways until we get that worked out you can see a demo here: http://jsbin.com/ibihi