top of page

Oracle APEX Accessibility Cheat Sheet

  • Writer: Samuel
    Samuel
  • Jul 3
  • 3 min read

Accessibility is a legal requirement and here at RADAPEX we continue to push this message. Below is a summary of the actions you must have taken to ensure your application is compliant with WCAG 2.2.


What Do I Need To Do?

Provide an Accessibility Statement & Accessibility Conformance Report. These should be available from your app. These tend to be in the footer of an application.


Sky Accessibility Statement Location
Sky Accessibility Statement Location

Use automated tools + manual testing (keyboard, screen reader).

Conduct user testing with people with disabilities.

Document known accessibility issues and remediation plans and update your Accessibility Statement & Accessibility Conformance Report regularly.


At RADAPEX, we advise that accessibility appreciation is an additional skill that as an App Developer you must contain. We are advocates for accessibility and we encourage it to be part of the DevSecOps Developer role respecting accessibility as much as security.


  1. Skill-up on Accessibility, there are loads of great blogs and training material out there.

  2. Develop and continually challenge Accessibility as part of your peer review process.

  3. Include AX Automation tooling as part of your CI/CD pipeline.

  4. Ensure Manual testers are skilled-up on Accessibility.

  5. Ask independents from the community to experience and enjoy the app.

  6. Produce an Accessibility Statement and Conformance Report.


General Setup

  • App uses the Universal Theme (UT).

  • Accessibility Mode is enabled (App > User Interface > Accessibility Settings).

  • All pages follow a consistent layout and structure.

  • All actions (modals, buttons, links) work without a mouse (keyboard accessible).

  • No flashing, blinking, or animated content without controls to stop them.


Page Structure & Navigation

  • Each page has a unique and descriptive title.

  • Page regions use semantic headings (<h1>, <h2>, etc.).

  • ARIA landmarks (banner, navigation, main, footer) are properly implemented.

  • Keyboard navigation works across all interactive components.

  • Focus order is logical (left-to-right, top-to-bottom).


Form Controls & Inputs

  • Every form input has a visible label.

  • Labels are associated using APEX’s Label property, not placeholder text.

  • Required fields are indicated clearly (not just with color).

  • Form error messages are:

    • Clear and specific

    • Programmatically associated with the input (aria-describedby)

  • Descriptive help/tooltips are available where needed.


Regions, Buttons & Components

  • All buttons and links use meaningful text (avoid “Click here”).

  • Icons used alone have accessible labels (aria-label or hidden text).

  • Modal dialogs:

    • Trap keyboard focus inside when open.

    • Return focus to the triggering element on close.

  • Interactive components (tabs, accordions) support:

    • Arrow key navigation

    • Role and state attributes (e.g., aria-expanded, aria-selected)


Reports & Charts

  • Charts use accessible mode (Chart Attributes > Accessibility).

  • All chart elements have descriptive labels.

  • Interactive Reports/Grids:

    • Columns have proper headers.

    • Row actions are keyboard accessible.

    • Data summaries are available or easily added.


Colors & Contract

  • All text has a contrast ratio of at least 4.5:1.

  • Large text (18pt+) has at least 3:1 contrast.

  • Colour is not the only way meaning is conveyed.

  • Theme colours tested with UT Theme Roller Contrast Checker.


Dynamic Actions & JavaScript

  • All dynamic updates (e.g., region refresh) notify assistive tech:

    • Use aria-live regions when appropriate.

  • Focus is managed properly during changes (e.g., after a dialog is opened).

  • No custom controls break keyboard or screen reader functionality.


Mobile & Responsiveness

  • Responsive layouts work properly in zoomed and mobile views.

  • Buttons and links are large enough to tap (minimum 44x44px recommended).

  • All touch actions have keyboard equivalents.


Testing & Validation

  • App passes Lighthouse Accessibility audit (Chrome DevTools).

  • App tested with screen readers (NVDA, VoiceOver).

  • Keyboard-only testing has been performed.

  • Automated tools used (e.g., axe, WAVE, SiteImprove).

  • App tested by users with real assistive tech or disabilities (if possible).


Documentation & Maintenance

  • Accessibility is part of design and development checklists.

  • All developers are trained in APEX accessibility techniques.

  • Changes to components are checked for impact on accessibility.

  • Accessibility test results are documented and tracked.




 
 
bottom of page