Making APEX Applications Accessible

Accessibility for many people means "do I have the authority to access something?" but for many other people, accessibility means can I get the information I need due to physical limitations in how I interact with the system. Mostly, these people will have disabilities of some sort (vision impairments, mobility issues that prevent the use of a mouse etc). We, as developers, need to spend time ensuring the APEX applications we produce allow these individuals to interact with them without any additional hardship. APEX is very good at accommodating these accessibility features out of the box. However, there are many pitfalls that are easy to fall into as we develop an application. I'm going to show some of the main issues I have seen recently and how I resolved them. Within this blog, I will not point out specific problems with APEX and how to resolve them. I will, instead, explain some of the general issues with accessibility, how to identify them and some general ideas for solutions. I will cover the specific APEX issue and solutions in a later blog.

Simple changes

There are a couple of simple changes that you can make to your APEX applications that will ensure they become significantly more accessible and can be implemented quickly across the entire application. These are font, font size and colour palette.

Fonts are important as they give an application an identity. Using the same font across the application for a specific reason brings a consistent user experience. It allows the user to know what a message entails, even before they have read it. Using the same font for all error messages is a good example. However, some fonts are difficult to read, especially for people with poor vision, so it's important to use clear fonts. For font size, it is recommended to use a font of at least 14 points to ensure that they can be easily read, as well as reducing the need for end users to zoom in using the browser zoom (more on that later). Font and font sizes can be quickly set up as an application standard within your templates or in a CSS file loaded at the application level. This ensures that, unless specifically overridden, the fonts used throughout the application are the same size. This is good for the customer experience, and the sufficient size satisfies accessibility requirements.

The colour palette is a little harder to enforce, but by setting up your colours within the theme roller, they will be automatically applied application wide. It would also be beneficial to think about the palette and set up CSS within a file at the application level so that all colours are consistent across the application, easily maintained and accessible. There are many resources on the internet to provide colour palettes with sufficiently contrasting colours that still work with each other. There is no correct way of creating a suitable palette as there are lots of colours that contrast with each other, but there are several wrong ways of doing this. Stay clear of colours common in colour blindness, such as red, orange, brown, and green (see here for a more definitive list). Also, try not to have similar colours that are lighter in shade (green and pastel green, for example), as these can be easily confused. Finally, light pastel colours can prove difficult to see for some as they may be hard to distinguish from a white background.

Checking for Failures

So, how do you know if your APEX application is accessible? There are several tools and manual checks that you can utilise to identify major issues as follows:

Browser Tools

The first place to start that will give you a good base to work from will be to check your pages are accessible from a basic point of view, i.e. that there are no obvious issues. This can be done through browser tools in the Developer Tools Suite. If you didn't already know, go to your browser and hit F12. This will bring up a new window (or partition your current browser window depending on how it's configured) and display a lot of information such as the console output, a full listing of the generated HTML, performance logging, network file access and many more features. The tool I would recommend, and one of several that Oracle uses in their internal testing, is called 'axe DevTools'. This needs to be installed as a plugin, but once installed, it should appear as a tab in the browser Developer Tools. You can see it in the screenshot below:

To analyse your page, click on the Full Page Scan button, and it will analyse your page and describe any accessibility issues that it finds. There are also other tools that do a similar job. One that comes pre-installed in Chrome is called Lighthouse (you can see it in the picture above, next to axe DevTools), but I found that this missed one or two accessibility issues that axe identified. However, there is no reason not to use both (or more) to ensure you are checking for the broadest amount of accessibility issues.

There are two main drawbacks to axe DevTools. The first is that it only scans a single page at a time (the multi-page user flow analysis is still a beta product as of the time of writing this blog). So, it can be a little time-consuming, especially if your APEX application is large, with hundreds of pages. The second issue is that this (and other tools) only identify some accessibility issues as they can only scan the HTML and not identify how other accessibility issues are addressed, such as screen readers, keyboard navigation and reflow due to high zoom levels. However, it does give a good starting point and will identify where screen reader tags are missing, for example. I recently built a new site where every page had a 100% pass rate on axe DevTools, but the Accessibility Lead still found nearly 20 other failures that needed addressing, so don't just use these in-browser tools and think that's enough.

Accessibility Tools

There are several tools that users make use of to aid in their use of websites. Some utilise keyboard navigation (if they have a physical disability that prevents them from using a mouse or from being able to see the mouse pointer), in-browser zoom to better see the web page if they have some sort of visual disability, or even screen readers for blind or severely visually impaired individuals where the computer will read out aloud the text on the screen, menu options, button clicks etc. All these also need to be considered when dealing with accessibility.

In-browser Zoom

This is the easiest to replicate as it involves you as a developer zooming in and out (ctrl & mouse scroll wheel or +/- on the keyboard). APEX does a good job of reflowing applications as the zoom increases or decreases, but as developers, we are used to large screens, multiple screens or even both as we need these to effectively do our job. End users usually do not, and if the end-user is a member of the public, they may be accessing the site on a small laptop screen or even a mobile phone. If you zoom in on a smaller screen (which many accessibility users do), the amount of screen real estate is significantly reduced.

One of the big issues that can be seen within zoom levels is if the user can see the information they are looking for. Accessibility zoom levels are checked up to a zoom level of 400%. If your application has a logo, menu bar and breadcrumb bar, then at a zoom level of 400%, there isn't much room left to display the actual page contents. This is where collapsible menus can be utilised, maybe smaller logos or logos not displayed in the header so that it scrolls off screen as the user scrolls. Breadcrumb bars can be handy in some situations, but do you really need them on every page?

The above image is taken from a mock-up page without a logo on a 1920x1080 laptop display and normal (100%) resolution. The screenshot below is the same application page on the same laptop screen, but this time at a 400% zoom level. Note just how little area there is to display the text in comparison.

You need to also think about padding. On a large screen with no zoom, padding can make a site look neat and professional, but on a small screen with a high zoom level, that padding suddenly results in large gaps between elements and little web content being visible. APEX does a good job of reflowing pages, so one recommendation would be to use the twelve columns that APEX provides to position content as needed instead of utilising CSS, as APEX will reflow these better. It also means that as accessibility bugs are fixed within APEX, the application would automatically receive those fixes when an upgrade is applied instead of having to go through each element and update CSS. Additionally, using styling to position elements may cause issues during the reflow. I have seen fields move over each other instead of reflowing one under the other due to the additional CSS. This is not always possible, however, and sometimes CSS is what is needed for positioning an element, so there is no right or wrong way. You may have to make adjustments through trial and error, as what may work at one zoom level doesn't at another.

Keyboard Navigation

Keyboard navigation is where the mouse is not used at all, and the user navigates around the page, clicking links etc, through the keyboard alone. This means that you must check the order that a user can tab through is obvious and sequential (tabbing only utilises clickable links, not standard text). Menus need also to be navigable and in the correct order. For keyboard navigation, scrolling horizontally is difficult, and as such, you should not create content that utilises this where possible, which on high zoom levels can be extremely hard to do, so sometimes you may need to think about whether a multi-column report is the best way to display your data.

One relatively unknown feature is the "Skip to Main Content" button. This is a special button that is normally hidden, but on entering a page and the user presses the tab button, a hidden button appears that allows a user to navigate to the main content, skipping over any menus. This must be the first element on the page, so if you don't see it when pressing tab, it may be that you have set focus to another element. What the main content is can be customised by the developer by adding a tag at a specific point in the HTML, but this is usually the first piece of content after the menus. This is so that a keyboard user doesn't have to navigate through all the menu options to get to the content they are interested in. It's easy for non-disabled users to see the rest of the content on the screen or to use the mouse to quickly move to a clickable link somewhere, but a lot harder when you have to use the arrow keys or tab keys to move through each menu option first.

Screen Readers

Screen readers are very powerful software applications that allow visually impaired users to access computer systems, including websites and APEX applications, which are accessed through the browser. Windows 11 now comes bundled with a screen reader; however, this is quite basic and simply reads the text on the screen. The application I recommend that you test against, and one of the readers that Oracle uses to test APEX against, is called NVDA. This application reads out lots of information that the end user would benefit from but is taken for granted by non-visually impaired individuals, such as the number of items in a menu (e.g. reads out loud "Item 1 of 4, Home").

Screen readers will utilise the aria tags in the HTML. In most instances, APEX will automatically create these. But sometimes you may need to provide different tags or even prevent the tag from being generated using aria-hidden to ensure something does not get read out. One area where screen readers struggle is when the focus shifts as they stop reading where the focus was and start to read out where the focus has moved to. This is fine if the user has moved the focus themselves as they are expecting it. However, if the application moves focus itself for any reason (for example, if the page automatically refreshes every 5 minutes), then this may cause the screen reader to say unexpected things. This could result in the end user becoming confused as to where they are on the page. It is, therefore, important to test your application against a screen reader and to ensure that you test as many situations as possible and listen carefully to the output. It is possible to split the focus so that there is a "mouse" focus (like hovering your mouse over a page item) and a "keyboard" focus, this can also alter how the screen reader works and can add confusion. In one of my applications, this caused the menu to be read out completely wrong, including the page title with each menu item.

Upgrading APEX to the latest version

OK, this one seems straightforward, but maybe not for the reasons you are thinking. Most developers want to work on the latest versions, and businesses must keep up with releases, or they may go out of support. But, from an accessibility point of view, each new version of APEX has introduced many fixes to address accessibility issues. For example, between APEX 22.1 and APEX 24.1, there have been 246 accessibility fixes to the APEX system, covering almost every aspect of the produced page code as viewed by an end user. If you are struggling to identify a solution to an accessibility issue, I would first look at this Oracle site to see if a fix has already been made and then see if the APEX environment can be upgraded to potentially resolve that (and other) issues. If your company doesn't already, I suggest creating an upgrade schedule, so you are never too far behind the current release.

Site Map

Although not a legal requirement, unless your application is small and consists of only a few pages, it would benefit some users who struggle to navigate menus to have a site map page in your application where all pages are linked. This would allow any user to quickly navigate around your application without the need to access the menus. For most of us, menus are easy as we can see where the menu link is, we can see the menu expand (if it is that sort of menu), and we can see the links as they are presented and click on the correct one with the mouse. But for people with visual impairments, this is much harder as they will probably use keyboard navigation and a screen reader, and they may not be able to easily navigate to the menu if the current focus is on the middle of the page at that time. It's also important that the link to the site map is easily available on all pages and that the page is simple and clearly laid out.

Legalities

Making APEX applications accessible is a legal requirement, and all public-facing sites must contain an accessibility statement. This statement must declare when the site was tested and when it will be looked at again. It must also detail all non-compliant elements of the site, stating which accessibility rules have been broken and when each failure will be fixed. The page must also detail how to contact the company to report accessibility issues or ask questions about accessibility.

Conclusion

Accessibility is a major part of any APEX application, even internal facing ones. Many more people are now gaining access to computer systems through the improvement of technology that allows them to do so. As developers, we must strive to allow as many individuals as possible to use the applications we build. As such, we must ensure accessibility is built into our applications as much as possible. Application design needs to include accessibility from the start as this is easier to do at that stage, requires minimal additional development and is easier to maintain going forward. Often, development doesn't even think about accessibility, or it's an afterthought and bolted on after all other testing has concluded.

For more information, check out our Oracle APEX Services, and if you liked this blog, check out our other APEX blogs here.

Subscribe to Oracle APEX Insights if you want to stay tuned for more APEX updates.