I have recently inherited a web app using the EXTjs framework. I'm not really that familiar with it, but I have been learning it the best I can over the last few months. I have recently been given an assignment to update the entire application to comply with 508 Compliance, that is to say, make the application accessible for those with vision issues. I was given a deficiency list that gives examples where the software doesn't comply for various reasons. I guess I need a little help in understanding how this works. I've looked at the EXTjs documentation and it does say that it has accessibility features available in it, but I haven't really been successful in finding what to do. Those using the application are using the JAWS screen reader if that makes any difference.
A few of the things I know that I need to fix are:
Some elements need to be tagged as a heading so the screen reader can read it programmatically an to give the web page some structure.
When tabbing around a table/grid the data is read without any context/header information.
Color is used as a visual cue to indicate action(ie required field). I'm supposing this is for color blindness and some other visual cue needs to be added.
Modal windows can't be resized or moved by the keyboard.
Needs a mechanism to bypass blocks of content that are repeated on multiple pages.
Pages do not have titles(this is a single page app).
Keyboard operable UI elements do not have a visible indication of focus(radio button group doesn't show focus, even if selected one does).
Name/State of UI elements in the product can't be understood(ie the name of expand and collapse buttons are read as expand panel or collapse panel by assistive tech without context to what is being expanded or collapsed).
There are many other issues, but this gives some idea of the scope of the changes required. As I have stated above, I've done a lot of examination of the EXTjs documentation at their site as well as google searches on how to make applications more accessible. But I'm not really seeing what I need. Much of this application is just configuring EXTjs templates and then loading them with much of the meat of the application being handled by the EXTjs built in js code.
I would appreciate any help, useful sites with examples, or code snippets on how to accomplish some of this. I'm hoping that once I get started with some examples, I can just go on from there.
Thanks.
Most items come with aria support. Personally I would add look into each component and add an automated aria support. E.g. button ==> aria.label = button.text
Take a look at ariaAttributes, ariaDescribedBy, ariaLabel and ariaLabelledBy. Some have ariaErrorText, ariaHelp.
Next take a look at tabIndex. You want to ensure that you can use TAB to jump through the fields, buttons, ...
Related
We're using a CMS that provides a broken link report; however, that broken link report is useless to us because it detects some 1,300 links as broken because they are deep links into many different screens in our web app product. (I.e., a static HTML page links to a web app that requires authentication that our authoring tool can't process so it flags the link as broken - 404.)
Ideally, we'd be able to rely on the CMS reporting of broken links, and one thing I know works is to use an onclick event instead of an href. But I would like to know if there are reasons we should not do that.
Admittedly, I've read quite a few threads asking similar questions about onclick="function()", but they all seem a shade or two different from what we're trying to accomplish.
Is it okay to use an onclick event for these links instead of the standard href? (See code below.)
What problems or limitations would we encounter if we did? (For example, I'm not sure we'd be able to test if these onclick links actually work, at least not via automated link checkers, and that may be okay.)
Are there other options to have these links essentially skipped over by a broken link crawler/checker?
I'm looking for a better understanding of best practices here.
Thanks
Link Text
<span onclick="location='[[relative path to web app]]'" class="uxlink">Link Text</span>
onclick breaks accessibility for screen readers. You need to add all your ARIA features manually. It also breaks SEO because crawlers can't follow the link.
I am having trouble figuring out how to do even the simplest things in Alfresco, like typing a simple document. I've been Googling and noticed that customizations can be done through HTML documents. I need help and decided to post a question to a knowledgeable user platform. THe following customizations I would like are WAY far fetched and most likely not even achievable, but any help that can be provided I would really appreciate.
*list items in bold are most important
Anyone could be assigned a login and when they logged in they would have access to and easily view all of the contents of the site (or multiple sites that make up one accessible website?)
All of the items on the website would be a hierarchy, the user facing contents of the site would be a list of links with thumbnails, when one link was clicked it would be another list of links with large thumbnails, when one of those links was clicked a text document would be brought up, that document would contain clickable sections, when one of those sections was clicked it would bring up a page only containing the section clicked:
Links (crafts)
2nd layer of links (modules)
Text and image document with clickable links (single module containing clickable sections)
Section (single sections of module)
The module and section text would also contain images and tables throughout and mixed in the text
If a link (module or section) was used in multiple places all instances of the link would be linked to each other. If on instance was edited, the other would also change. THis setting could be turned off for any individual link if necessary.
Every document should have an easy to use live commenting system (something simple like Disqus would work) The comments are the most important on the single section pages but would also be good on the module page
An advanced tagging system that would be part of the entire site/website environment. A user could type anything they wanted as a tag and use multiple tags. The tags would be used for their comments on the content (text, sections) but the tags could be searched (most importantly by the administrators of the site) at any time in the whole environment. A popularity of any tag could also be viewed (I'm not sure how that would work, possibly another section of the site or an easy to see column on any text/image document?)
A user could edit their own comment if they wished but would not be able to delete it entirely. Comments would also be date and time stamped.
I know all of this is most likely impossible but if anyone has an idea of Alfresco customizations that could pull any of this off, or of an entirely different secure platform or site that would perform anything similar to this please let me know.
Thank you!
It sounds like you are looking for a Web Content Management (WCM) System. Alfresco is a Document Management (DM) System. You can use Alfresco as a back-end for a custom content-centric solution, but if you are expecting to install it, start it up, and have anything close to what you've listed above, you are barking up the wrong tree.
Everything you've listed is a front-end concern. You can use whatever you want to develop that functionality, but none of it will leverage Alfresco unless you choose to store some of the data in the Alfresco back-end.
You might be better off looking at something in the WCM space, such as Drupal or Wordpress. Or if you want something Java-based, look at Magnolia CMS or Hippo CMS.
I have a question about Javascript widgets. The widget I am working on simply embeds content on a page instead of using iframes. So far it looks good. But there are cases where some users layouts are messing up the widget. For example, the widget might require a width of 300px to appear. But the parent div is set to 250px and hence the right part of the widget is cut off.
I was wondering what sort of precautions should be taken to prevent this? I was talking to the product manager who mentioned he wanted me to check the parent div elements and get the size and then show an alternate message if their size is not accurate. But again, since this is Javascript and the widget is supported in many diff browsers(including IE6), I am wondering how fail-safe this method would be? What if I need to iterate the DOM all the way up before getting a valid size? I am also worried about performance here. This extra checks would slow down the delivery of my widget content to "good users" since I am adding a layer of complexity to all users. I don't want to penalize good users just because of the few errant ones.
I am not using any sort of JS library here, so any solution should not suggest the use of one. Also, the reason for not using a library was simply not to add extra weight to the page load to deliver a widget. I understand that "jquery" for example is small, but in my case, even 24k compressed seems like an overkill for a widget delivery that contains no core code for the widget.
Has anyone dealt with such issues before? What are your solutions to these?
There are reliable ways of determining the size of an element using JavaScript. You're quite right that you may need to iterate up the tree in some cases, but the answer you get will ultimately be quite valid.
Although you don't want to directly include any library code in this project, you may consider looking at how the major libraries implement their "what's the width of this element" functions to drive your own implementation.
Beware of quirks mode too.
I'd check to see of the page has Jquery, if not load it into the page using no-conflict mode. Then use jQuery to examine the page.
See: How to embed Javascript widget that depends on jQuery into an unknown environment
I'm learning jQuery and am about to write some pages using intensively that library. I just learned that some user disable JavaScript on their browser (I didn't even know that was possible and/or necessary).
Now, here's my question: What happens to my web application if a user disable JavaScript? For instance, I'd like to display some screens using AJAX and commands such as 'InsertBefore' to bring in live a DIV that will display the result.
So, if JavaScript is disabled, I wonder what going to happen to all this work that relies on JavaScript?
I'm kind of lost.
Thanks for helping
You may want to start by reading on Progressive Enhancement and Unobtrusive JavaScript.
I would also suggest to investigate how popular rich web applications like GMail, Google Maps and others, handle these situations.
I just learned that some user disable javascript on their browser
I do. The "NoScript" plugin for FireFox does the trick.
So, if Javascript is disabled, I wonder what going to happen to all this work that relies on Javascript?
It won't be functional.
A good practice suggests designing a site not to rely on JavaScript for major functionality. At least, accessing its content (in read-mode) should be possible. JavaScipt should only add interface enhancements like Ajax techniques etc. But the fallback version should always work.
I feel really sad when I see a site which is completely broken without JavaScript. Why can't people use CSS to put elements in proper places? Why do they try to align elements with JavaScript even if there is no dynamics involved?
The same goes for Flash sites. Once in a while a land upon a "web-design-agency" site which makes picky comments about me not allowing JavaScript. When I do I only see a basic primitive site with a few menus and that's it. What was the point of using Flash when the work is so primitive it can be done with raw HTML and CSS in an hour? For me it's a sign of unprofessional work.
All what's done in JavaScript won't work. Some users disable it for security reasons, NoScript is an excellent example. You can try it yourself by removing the scripts from your page or installing the NoScript-plugin for Firefox.
As a rule of thumb:
Make the website working with only semantic HTML
add the CSS
add the JS
But the website should be (almost) fully functional in stage 1.
If you disable Javascript in Safari things like Lexulous in Facebook won't work properly, the mouse letter carry function doesn't work.
We have a nav that expands on rollover (based on this code: http://www.dynamicdrive.com/dynamicindex1/droptabmenu.htm).
First, should we have a no-javascript version of the nav?
If yes, what is the best way to do so?
Yes you should always have a non-javascript version of your navigation.
The best way to do this is to apply any styles that hide sub-menus with javascript - so if the javascript isn't run the whole menu will be visible.
The HTML for the menu you've linked to looks fine - <ul>s and <a>s - nice and easy for a spider or non-javascript user to read.
It's always a good idea to have a no-Javascript version of everything.
Search engine robots usually do not interpret Javascript, so your pages might not be indexed if they can't be reached without Javascript.
A sitemap page that simply has a link to every static page on your site is the easiest way to make sure everyone can get to anywhere.
You may want to use unobtrusive javascript, which basically means have no javascript in your html page, just load the javascript files.
Now, if you start with a menu on the left, for navigation, using <li> and anchor tags then you can have some navigation without javascript.
So, if your javascript runs, the first thing it should do, when the dom tree is ready, is to set display: none on the navigation div and put in the new, more interactive navigation bar.
This way you can see how it works without any javascript.
Or, you can have a message telling them that javascript is required and do nothing else, but this would also be hidden as above.
I prefer to have things work, even if it has less functionality, without javascript, when possible.
Don't get me wrong: It's a good idea to support browsers that don't have JavaScript turned on, especially for something as simple as a menu.
However, when a project doesn't have it in the budget, or the application that you're writing is deeply dependent on JavaScript, it just doesn't make sense to support it.
Statistic from w3c and the counter indicate that 93% to 95% of users have JavaScript enabled. Now, mind you that this is a global demographic. To really determine if it's worth your time and money, it would behoove you to do your own statistics to determine what percentage of your traffic/demographic has JavaScript enabled.
As a side note: for reasons similar to why people are moving away from supporting IE 6, my company is also moving away from noscript support. Especially in large scale RIA's, it's just not practical to write the same thing twice. Maintaining two code bases for one project is not my idea of a good time. But of course, this is always based on the client and the target demographic.