When working with widgets that map directly to basic HTML controls (e.g. button, checkbox, etc), no additional work is required to enable a screen reader, as the readers are already able to interpret standard HTML tags. In addition to the basic widgets provided by the HTML specification, Rich Internet Applications commonly contain more complex widgets that are rendered using generic HTML tags such as the DIV tag. To make these complex widgets accessible to a screen reader, the W3C organization has defined the Accessible Rich Internet Applications (WAI-ARIA) specification (http://www.w3.org/TR/wai-aria/). This specification defines the 'Role' attribute for all tags, which can be used to instruct a screen reader on how a widget should be interpreted (e.g. "checkbox"). All widgets found in an EGL Rich UI application contain the fields "ariaRole", which can be used to instruct a screen reader on how to interpret the widget.
An example application that uses the "ariaRole" field is provided as part of the attached project, in the file AraiaRoleDemo.egl.
Another common aspect of Rich Internet Applications is the usage of widgets that update their content as the application is running, without re-rendering the entire page (e.g. stock prices, etc). To support these widgets, the ARIA specification defines the 'Live' attribute, which can be used to instruct a screen reader to re-read a widget's content after it has been updated. All widgets found in an EGL Rich UI application contain the fields "ariaLive", which can be used to instruct a screen reader on how often to re-read a widget after its content has changed.
An example application that uses the "ariaLive" field is provided as part of the attached project, in the file LiveRegionDemo.egl.
When developing an application, it is important to consider a user that does not have a mouse or other pointing device. To support these users, the application should enable tabbing so that the application can be used with only a keyboard. All widgets found in an EGL Rich UI application contain the field "tabIndex", which can be used to indicate the Tab order for the widget in the running application.
An example application that uses the "tabIndex" field is provided as part of the attached project, in the file TabIndexDemo.egl.
When developing Rich Internet Applications, it is a good idea to size elements using relative values, so that the application will render correctly on different size monitors or at different resolutions. To specify that a widget should take up a certain percentage of the screen in an EGL Rich UI application, you can set size attributes using a value with a percentage (e.g. width = "50%").
Font sizes should also be specified using relative units (e.g. em) instead of fixed units (e.g. px), so that the browser can adjust the font size to the users preferences. You can specify font sizes with different sizes and units (e.g. em, pt, etc) using the "fontSize" attribute found on all widgets in an EGL Rich UI application.
An example application that uses relative sizes and units is provided as part of the attached project, in the file RelativeSizeDemo.egl.
Note: The attached project, AccessibilityDemo, requires the com.ibm.egl.rui_1.0.2 project.
Attachment: AccessibilityDemo.zip[Read More]
The developerWorks Connections Platform is now in read-only mode and content is only available for viewing. No new wiki pages, posts, or messages may be added. Please see our FAQ for more information. The developerWorks Connections platform will officially shut down on March 31, 2020 and content will no longer be available. More details available on our FAQ. (Read in Japanese.)
From archive: November 2009 X
If performance of the generated program is significant to you, then it is important to understand the performance characteristics of EGL syntax alternatives in the different runtime environments.
A new white paper, EGL Best Practices: Coding For Performance, provides insight into this topic for EGL programs destined for Java or COBOL environments.
Please feel free to use this document. Comment on information that you feel was especially important to you or point out issues or scenarios that you would like addressed with more detail.[Read More]
Our apologies for this, but any existing EGL applications using the 0.6.0 version of the Dojo Widgets will most likely require changes to bring them forward. That said, the current API has been firmly defined and will not experience significant changes in future releases.
To download the EGL Dojo Widgets for RBD click here. Be sure to also take a look at the great documentation attached to the page to get a feel for the API.[Read More]
Fix pack 126.96.36.199 is now available. It includes fixes in many areas of the
product, as well as significant runtime performance improvements in both Java and COBOL environments. Everyone using RBD 7.5.x should install it. See IBM Rational Business Developer 188.8.131.52 Release Information for more info, including installation instructions and the list of APARs which are fixed. The download instructions are here.
If you generate COBOL for System z, you should also install PTF UK51729.
Rational Business Developer version 184.108.40.206 includes these enhancements:
If you have been using Rational Business Developer (RBD), you'll notice a few things are different in EGL CE. First, you'll probably notice that EGL CE has a single EGL perspective. For developing EGL, there is a single EGL editor that determines whether to show the Design and Preview tabs based on the content of the file opened. To create an EGL project, you are required to enter only a project name. Because it combines features from the General and Rich UI project types from RBD, a single EGL CE project can contain Rich UIs, Web services, or both. By default, each EGL CE project depends on the EGL Rich UI widget project and a Dojo runtime project. Simply drag-and-drop any of the widgets from the palette onto the visual editor in Design view. Use the Properties view to customize each widget and define events.
Like RBD, you can use EGL CE to code, preview, and debug RIAs before you deploy them to an application server. In EGL CE, services can be tested in Preview or debug using the service's source code if it's in your workspace or using the deployed version for existing services. Being able to see your application in action using Preview and Debug, make quick changes, and test again speeds up the development process a lot. Once you're happy with your application, you can deploy it.
Deployment in EGL CE is somewhat different too. EGL CE removed the need to switch between deployment and development modes since code is automatically generated for debug and target deployment (see the EGL CE Project Structure and Code Generation blog). For deployment in RBD, you select a single Rich UI handler to serve as the entry point to your application. In EGL CE, you can better control how your application is deployed using the Deployment Descriptor editor. By default, all Rich UI handlers create an HTML endpoint for each specified locale in EGL CE. You can edit the application's deployment descriptor (.egldd) to pick each Rich UI handler you want to have an HTML endpoint, and therefore you control the entry point URLs for your application. In the deployment descriptor, you can also determine what types of services to create such as SOAP or REST, and the service client bindings that tie your front-end user interfaces with the back-end services. Each deployment descriptor has one Web project as the target. If you want parts of your application to run on different targets, you can create multiple deployment descriptors, for example a descriptor to deploy Rich UIs to one target and another descriptor to deploy services to a second target. Currently, EGL CE supports deployment to Apache Tomcat.
So if you want to develop Web 2.0 applications quickly and efficiently, try EGL CE. We think learning a single language like EGL will make your life easier, as well as reduce the strain on your bookshelf since you won't need a bunch of reference manuals. And it's free, so you can try it without asking your boss for a purchase order.
And remember, the C in EGL CE stands for community. We encourage comments and feedback from you, the EGL community. Feel free to ask questions in the forum, comment on blog posts, or contact us to write a blog post yourself. Let us know what you think! We'd love to hear from you.[Read More]