Home

News: How accessible is JSF ?

  1. How accessible is JSF ? (26 messages)

    Hi, I am currently working for an organisation that has accessibility high in it's requirements list. Accessibility has many sub-requirements but maybe one of the most painfull requirements is that fact that your web app must work in browsers without Javascript. One big question pops up in this case: how accessible is JSF ? JSF being the standard pushed by Sun and the JSR community, must have an answer to this otherwise the standard wouldn't be very usefull, would it? Unfortunately I haven't found much information about this. So I am asking this question to the Serverside community. Are there any JSF frameworks/component libaries that can work without Javascript? Will JSF 2.0 have better support for accessibility? Or should we be looking for another standard next to JSF?

    Threaded Messages (26)

  2. Re: How accessible is JSF ?[ Go to top ]

    Accessibility is a tricky issue and even though I am no JSF expert (may be JSF gurus can comment better on the issue), I believe there is no framework in the market to help you achieve the browser downgrade gracefully. At the end you have to roll down your sleeves and do it your self by avoiding the hype like (Ajax) if you can, reduce the unnecessary javascript code, and follow the good HTML design rules.
  3. JSF Spec should address AJAX part along with Server Push (I saw these topics in JSF draft spec) It should also be able to support client side rendering with Entities and BackingBean callable from javascript (like seam remoting) and it should also support storage abstraction as IE8 and Firefox3 has it inbuilt. Otherwise again it will suffer same fate of earlier jsf where industry is moving in one direction and jsf is taking another. If i want to compose application using javascript, html, css alone in the client side without using JSP/JSF for every request in the server side (minimal framework components based on servlet or jsf), i can do it with Seam Remoting and Dojo. I can develop a true model/view/controller in java script and expose my services or beans or whatever components as javascript component by having javascript to java communication layer fabricating security and other aspects into it. So how does JSF support this? The very idea is lot of Javascript frameworks exists like GWT, Dojo, YUI, JQuery etc, those are specifically focused on client side computing, is there a way in new JSF spec which eases integration with these fw, so that we can give a great UI by exploiting them. It is much difficult to focus both client side and server side in speed with specific fw mentioned above. But there should be a way to leverage them. Otherwise money/time/effort spent on standardizing will not be usable by major crowd.
  4. JSF Spec should address AJAX part along with Server Push (I saw these topics in JSF draft spec) It should also be able to support client side rendering with Entities and BackingBean callable from javascript (like seam remoting) and it should also support storage abstraction as IE8 and Firefox3 has it inbuilt. Otherwise again it will suffer same fate of earlier jsf where industry is moving in one direction and jsf is taking another.
    If i want to compose application using javascript, html, css alone in the client side without using JSP/JSF for every request in the server side (minimal framework components based on servlet or jsf), i can do it with Seam Remoting and Dojo. I can develop a true model/view/controller in java script and expose my services or beans or whatever components as javascript component by having javascript to java communication layer fabricating security and other aspects into it. So how does JSF support this?
    The very idea is lot of Javascript frameworks exists like GWT, Dojo, YUI, JQuery etc, those are specifically focused on client side computing, is there a way in new JSF spec which eases integration with these fw, so that we can give a great UI by exploiting them. It is much difficult to focus both client side and server side in speed with specific fw mentioned above. But there should be a way to leverage them. Otherwise money/time/effort spent on standardizing will not be usable by major crowd.
    ICESoft does most of the things you are asking for using JSF. But if you have too much traffic or rich pages, JSF just blows up because of high memory requirement. We tried it for a few pages with about 50 html input elements and each page was eating close to 1MB per user session in our RAM. So if you have 5K to 10K concurrent user sessions, you will see smoke coming out of your servers :). Ofcourse you can put in a lot of servers to reduce load on one server, but still the RAM requirement is just way too high and unsustainable.
  5. You can make accessible JSF applications, but you have to avoid standard components (most notably h:commandLink) that work only when JavaScript is enabled. You might want to look at JSF frameworks like JBoss Seam or RestFaces. It is also possible to do this with plain JSF, but it gets awkward pretty soon. Daniel www.flexive.com
  6. you have to avoid standard components (most notably h:commandLink)
    Indeed you can use h:commandButton components instead and make those buttons look like links thanks to CSS.
  7. you have to avoid standard components (most notably h:commandLink)

    Indeed you can use h:commandButton components instead and make those buttons look like links thanks to CSS.
    If you need accessibility probably you need also bookmarkability. Use buttons for submit and links for bookmarkable resources. JSF permits this approach (you can use plain HTML links or h:outputLink component) but doens't encourage it. This is why many framework try to solve the issue: Seam, Spring Faces, Scala, RestFaces (I am the RestFaces developer ;)) etc...
  8. Spring Faces[ Go to top ]

    Hi, Check out Spring Web Flow 2 and Spring Faces (http://springframework.org/webflow) which use the Dojo widget system in a progressive manner, a manner that degrades gracefully if JavaScript is not available on the client. Try the demo application at http://richweb.springframework.org/swf-booking-faces/ with javascript enabled in your browser and then with javascript disabled.
  9. Re: Spring Faces[ Go to top ]

    Interesting... I will give a look.
  10. Re: Spring Faces[ Go to top ]

    Hi,

    Check out Spring Web Flow 2 and Spring Faces (http://springframework.org/webflow) which use the Dojo widget system in a progressive manner, a manner that degrades gracefully if JavaScript is not available on the client. Try the demo application at http://richweb.springframework.org/swf-booking-faces/ with javascript enabled in your browser and then with javascript disabled.
    Wicket doesn't force using any JavaScript (you can use Ajax but don't have to), and we have a couple of components that show how you can write degradable Ajax apps (for instance, see the AjaxFallbackLink component). If you'd ever consider using Wicket, I remember several people who said on the mailing list that they coded completely degradable applications; you'd be welcome to enquire on the list about their experiences.
  11. Re: Spring Faces[ Go to top ]

    Hi,

    Check out Spring Web Flow 2 and Spring Faces (http://springframework.org/webflow) which use the Dojo widget system in a progressive manner, a manner that degrades gracefully if JavaScript is not available on the client. Try the demo application at http://richweb.springframework.org/swf-booking-faces/ with javascript enabled in your browser and then with javascript disabled.


    Wicket doesn't force using any JavaScript (you can use Ajax but don't have to), and we have a couple of components that show how you can write degradable Ajax apps (for instance, see the AjaxFallbackLink component). If you'd ever consider using Wicket, I remember several people who said on the mailing list that they coded completely degradable applications; you'd be welcome to enquire on the list about their experiences.
    Ooops, sorry for plugging... I see now - after posting - the message I replied to was actually referencing Spring FACES (I thought it plugged Spring MVC). Anyway, I can imagine it is possible to do whatever you want with JSF, but like other people said, you'll have to pick your JSF implementation/ widget set with care, and I can imagine that client state saving won't be a good idea.
  12. I have to address this too, though I am dreading it because the quality of low level html of many kits is very poor. It is inexcusable for the markup to not be xhtml strict in 2008. (I use a validation filter to test my web apps). Javascript may be enabled and your app should consider how it changes a page, for example how new content will be read by a screen reader. The W3 calls their approach WAI-ARIA, here is an overview document. http://www.w3.org/WAI/intro/aria
    WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.
    I would like to see "WAI-ARIA compliant" on a good widget kit.
  13. It is inexcusable for the markup to not be xhtml strict in 2008. (I use a validation filter to test my web apps)
    How is it 'inexcusable'? Internet Explorer does not support xhtml. Unless you're serving your xhtml with a MIME type of application/xhtml+xml the browsers that actually should be supporting it aren't either. What's 'inexcusable' is that people somewhere along the way decided that xhtml looked shiny and new and implemented it, browser support be damned.
  14. Matt, XHTML is a way to have real consistency in the near future, compared to guessing at tag soup. But the topic here is accessibility. Just take a look at the markup some of these toolkits are generating. xhtml is not perfect, it still requires hacks, but at least it separates content from style, discourages using tables for layout, requires full tagging for multimedia elements, and other practises that will make a more accessible site (and typically better structured for decomposition and more flexibly styled).
  15. http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesinEJB3-Part4 is a perfect example of the WRONG way to use HTML. Tables should not be used for forms. Tables should only be used for TABULAR data (get it?) The reason for this someone using a screen reader will have to suffer through all the rows and columns and table information being read out, with facilities for using a table, even though it's not a table. "It's just an example," people say, but people are going to copy and paste this example in their own code. The standard of quality is very low, and willingness to apologize for bad style high. Too many people in the jee community are willing to use 1998 style markup.
  16. Re: How accessible is JSF ?[ Go to top ]

    I am currently a member of a team that is building an application that needs to be accessible. We are using JSF and I must say that's it's sometimes hard but it can be done. JAWS is the software that is used for blind people and javascript can be used. We use AJAX a lot without any sort of problems.
  17. Need help on Accessibilty on JSF[ Go to top ]

    Dear Sir,

    I am using JSF pages develop in oracle ADF 11g. I not build accessibilty on this.

     

  18. The notion that if you use Javascript in your web page your application is not accessible is wrong. Most disabled people use something like JAWS (screen reader) which does work with Web pages that have Javascript in them. For us at Oracle for example, we are using the ADF Faces set of components, and we need to build accessible applications. We have some guidelines documented here: http://www.oracle.com/webapps/online-help/jdeveloper/10.1.3/state?navSetId=_&navId=4&vtTopicFile=jsf_apps/adfcreate/af_aacessible.html&vtTopicId=
  19. In regards to making your web app work w/o javascript.... I have to ask: why?
  20. In regards to making your web app work w/o javascript.... I have to ask: why?
    google screen readers mobiles lynx bookmarkability - browser history (usually broken in such apps) accessibility and keyboard navigation - standard html controls are safer ect... If on the other hand its an application for use inside an intranet, organization or other controlled environment, then it doesn't make any difference. But generally, it seems that "Graceful Degradation and Progressive Enhancement" always produces better results (see the jQuery way of doing things).
  21. If on the other hand its an application for use inside an intranet, organization or other controlled environment, then it doesn't make any difference.
    Wow, I guess vision impaired and other users are not entitled to work? :\ The other point is that people using screen readers &c do use javascript. Read the W3C documents for the best practises.
  22. If on the other hand its an application for use inside an intranet, organization or other controlled environment, then it doesn't make any difference.


    Wow, I guess vision impaired and other users are not entitled to work? :\
    They are. When you deploy an app for use in an organisation with 100 users with IE6.0, then you can safely assume that javascript will be there. Its a slightly different thing than deploying for everyone on the www.
  23. Its a slightly different thing than deploying for everyone on the www.
    I agree, two years ago I've worked for a www site project, the client wanted to be sure that the site could be accessible to everyone in the world, thus, AJAX was discouraged.
  24. In regards to making your web app work w/o javascript.... I have to ask: why?

    google
    screen readers
    mobiles
    lynx
    bookmarkability - browser history (usually broken in such apps)
    accessibility and keyboard navigation - standard html controls are safer
    ect...
    My proposal: ItsNat. ItsNat is a server centric Java AJAX Framework: * google Google doesn't like AJAX, but you can add Google-friendly permalinks to your AJAX based applications. This example shows several techniques to do this. The complete ItsNat Feature Showcase is searchable by Google. * screen readers ItsNat approach generates very clean and highly controllable HTML. I agree screen readers are a problem for JavaScript based applications (because DOM is usually modified by these screen readers). ItsNat offers some support of components without JavaScript and without AJAX. * mobiles Today mobile browsers have changed very much, see this list: Opera Mini 4, Opera Mobile 8.6, NetFront 3.5, Minimo 0.2, Internet Explorer Mobile 6 (Windows Mobile 6), iPhone/iPod Touch, Android, S60WebKit (S60 3rd), Iris 1.0.8 and QtWebKit embedded (Qt 4.4). They all support JavaScript... and AJAX!! And supported of course by ItsNat. * lynx Do you really use lynx? :) * bookmarkability - browser history (usually broken in such apps) Use permalinks in your applications. * accessibility and keyboard navigation ItsNat supports a "joystick mode" in some components not based in forms (forms controls don't need this mode). In this mode a joystick (or a keyboard tab) and the enter key are enough to traverse and select elements in a list, table or tree. This example shows a data tree with this approach, it works in all supported browsers, specially Android (heavily based on joystick) and IE Mobile of WM 6 (yes that poor and buggy browser you can believe me).
  25. Uh! "permalinks to your AJAX based applications.This example" Bad link, this is the correct link.
  26. Hi David, As a web designer, I have worked on many government websites and Intranets in Canada, where compliance with W3C accessibility guidelines is mandated by policy. I can share some of my experience with you on developing for accessibility with JavaServer Faces. JSF, like many technologies, is a tool that can be used for different purposes. In fact, a better analogy would be a toolset, where the choice of instrument depends largely on the task the page designer is trying to solve and the needs of the audience you are trying to reach. If your target audience is a user demographic that expects high levels of interactivity, then as others on this thread have mentioned, you should choose a JSF component library that includes widgets with Ajax capabilities to add more dynamic behavior to your user interface. If your target audience on the other hand is the general public, then you must make sure the widest possible audience can access your JSF pages using screen reading devices, assistive technologies, and limited browser capabilities. Screen reading software can produce telling results when pointed at your JSF pages, enabling you to simulate the experiences of visually impaired users. I would also say that development tools have a lot to do with the accessibility of JSF pages. In this regard, I discovered long ago why Dreamweaver is the industry-leading web authoring tool and defacto standard in many Canadian government communication branches. One of the things I really love about Dreamweaver and the Dreamweaver community is the real care and concern for making sure that the markup and websites produced by Dreamweaver are accessible. The support for Web standards such as XHTML and CSS, W3C/WAI usability guidelines, and much more is simply second to none. As a JSF developer, I also appreciate the highly intuitive and mature Dreamweaver user interface. For Web development, the design-time experience in Dreamweaver is very enjoyable. Web authors benefit from a superb set of tools ranging from state-of-the art CSS rendering, accessibility wizards to convert pages from table-based to CSS-based layouts, built-in HTML validation, link checking, and much more. I also highly recommend the outstanding LIFT Machine extension from Jakob Nielsen. It features a sophisticated usability assessment tool that gives page designers real-time feedback on how to improve accessibility. You may also want to look at our product, JSFToolbox for Dreamweaver. It includes a suite of design and coding extensions for building JSF component-based user interfaces in Adobe Dreamweaver. Our users have commented on how well our tools integrate with Dreameaver's design environment. We specifically target Web page authors and Java developers seeking visual, drag-and-drop design tools to support rapid application development with JSF while producing accessible, W3C-compliant Web pages. Hope it helps! Ian Hlavats JSFToolbox - Design JSF Pages in Dreamweaver Read My Article on JSFCentral.com
  27. A posible solution[ Go to top ]

    Look at

    http://www.webaccessibilitygroup.com/jsf/jsf_accessible.php

    chrs