Trust center
Accessibility
Last updated:
Summary in plain language
This is Hooq’s own review of how accessible its screens are, for version 5.127.0. It is a self-assessment by the Hooq team, not an independent audit and not a certification. It combines a review of the interface code, automated checks, manual checks done by hand with the keyboard, and automated-browser checks at narrow widths, with enlarged text, with text-spacing overrides, on tooltips and on target sizes. No screen reader has been used yet.
Since the previous review (version 5.126.0) the admin pages gained keyboard-operable tabs, accessible names and labels for form controls and icon buttons, dialogs with focus handling, a confirmation before a Hooq is deleted, announced error and result messages, a clearly visible focus indicator, higher text contrast and support for the reduced-motion setting. 1 criterion (Reflow, 1.4.10) is rated “Does Not Support” after it was tested at a true 320 px width (three criteria were rated that way in the previous review). Many of these fixes are confirmed by automated checks only and are rated accordingly.
Main limitations that remain: results shown in the issue panel, dashboard gadget and Atlassian-built admin pages are not announced to screen readers, because the components offer no way to mark them; field labels in those pages have not been confirmed as bound to their fields; the Failed Syncs list and some headings lack table and heading structure; several status dots rely on colour for sighted users; four actions (such as clearing logs) do not ask for confirmation; some dialogs are not given focus back when closed from a row menu; every admin screen needs sideways scrolling at 320 px width and the issue panel is wider than a 320 px screen (Reflow is rated Does Not Support); the tooltip in the issue panel cannot be dismissed with Escape; and 0 criteria have not been evaluated yet (see below).
Related: Help centre troubleshooting, status. Questions or feedback about accessibility: [email protected].
Accessibility Conformance Report (VPAT 2.5, WCAG edition)
Product information
| Item | Value |
|---|---|
| Name of product | Hooq, by Limbus Lab |
| Product version evaluated | Production 5.127.0 (previous review: 5.126.0) |
| Report date | 5 October 2026 (updated; first issued 3 October 2026) |
| Product description | An Atlassian Forge app for Jira Cloud. Hooq keeps Jira work items in sync between two projects on the same Jira Cloud site or across two Jira Cloud sites: fields, status, comments, attachments, worklogs, boards and sprints, with per-Hooq configuration, approval and troubleshooting screens. |
| Contact information | [email protected] |
| Evaluator | Hooq team, self-assessment (code review, automated checks, manual keyboard checks and automated-browser checks (narrow width, enlarged text, text spacing, tooltips, target sizes) on a development installation; no screen reader) |
| Applicable standard | WCAG 2.2 Level A and Level AA. WCAG 2.1 Level A and AA criteria are a subset of these tables. Level AAA, Revised Section 508 and EN 301 549 tables are not included. |
| VPAT template | VPAT 2.5 (WCAG edition), ITI terminology |
Evaluation methods used
This report is a self-assessment of Hooq 5.127.0 that combines the following. It is not an independent audit.
- Line-by-line review of the admin pages (Overview, the Hooq workspace tabs and dialogs) and of the Atlassian UI Kit surfaces (issue panel, dashboard gadget and its settings, and the Get Started, Global Settings and Hooqs admin pages).
- Colour-contrast ratios computed with the WCAG relative-luminance formula from the real style sheet (48 listed colour pairs, all checked automatically).
- Automated checks of the code, run on 3 October 2026 and all passing: focus indicator and reduced-motion rules, accessible names and menu state, announced messages, dialog behaviour (focus moves in, Tab stays inside, Escape closes, focus returns), tab-list behaviour, form-control labelling (128 controls) and the delete confirmation. These show that the markup and rules are in place. They do not show how a screen reader announces them, so rows that rest only on them are not rated “Supports” where a manual check is the normal evidence.
- Manual keyboard checks, done by hand on one development installation of the same code (keyboard only, Tab, Shift+Tab, Enter, Escape, arrow keys): the arrow keys moved a visible focus ring along the five main tabs and the Configuration sub-tabs and wrapped around; every dialog that was reached (New Hooq, Rename, Delete confirmation, Notifications edit and preview, synced issues, Documentation) was opened by keyboard and tabbed through at least 12 times; Escape closed it and the menus; and focus was checked after closing.
- Automated-browser checks on a development installation (5 October 2026), run on all 17 admin screens (the Hooqs list, the Hooq tab, the five main tabs and the 11 Configuration sub-tabs), the issue panel and the synced-issues dialog: reflow at a true 320 px wide viewport (Jira insets the app frame by 40 px on each side, so the app gets 240 px; this is noted in the results); enlarged text, emulated as a 640 px wide viewport, which is what a 1280 px window shows at 200 % zoom (not a real browser zoom); the WCAG text-spacing values applied by script, comparing clipped boxes before and after; the tooltip in the issue panel by hover, keyboard focus and Escape; and target sizes measured on screen. An earlier round on 3 October constrained the app frame to 320 px and 640 px because the browser window could not be resized then; the later checks replace those results.
- Target sizes were measured on screen for every target listed in the remarks (about plus or minus 2 px).
- Review of the Atlassian Forge UI Kit documentation for the components Hooq uses. UI Kit components are rendered by Atlassian; their internal markup was not inspected.
Not evaluated yet
- No screen reader has been used on any part of Hooq.
- Not done by hand: tabbing through the Hooqs table and the Troubleshooting filters and table, Escape on the detail header menu, the Atlassian-built pages, and the issue panel (keyboard focus did not appear to reach its controls in the test; a keyboard user should check).
- Not tested: a real 200 % browser zoom and text-only zoom (200 % was emulated by viewport width), text spacing on the dashboard gadget, its settings, the Atlassian-built pages and the other dialogs, and reflow of the mapping dialogs.
- The rendered pages have not been scanned with an accessibility tool, and how the Atlassian components expose field labels has not been checked in a browser.
Scope: everything Hooq renders. Jira page chrome, navigation, sign-in and the frame that hosts the admin pages are provided by Atlassian and are out of scope.
Terms
- Supports: the functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
- Partially Supports: some functionality of the product does not meet the criterion.
- Does Not Support: the majority of product functionality does not meet the criterion.
- Not Applicable: the criterion is not relevant to the product.
- Not Evaluated: the product has not been evaluated against the criterion (used where a review without testing cannot decide the outcome).
In the remarks, “admin app” means the Hooq admin pages (Overview, workspace tabs and dialogs); “UI Kit surfaces” means the issue panel, dashboard gadget, gadget settings and three admin pages.
Table 1: Success criteria, Level A
| Criterion | Conformance level | Remarks and explanations |
|---|---|---|
| 1.1.1 Non-text Content | Partially Supports | Images carry text alternatives: project icons, work-type icons, the Hooq logo; letter fallbacks are hidden from assistive technology; decorative UI Kit icons use an empty label. Changed since 5.126.0 (confirmed by an automated check of the code, not by a screen reader): the dismiss buttons of messages, the overflow-menu buttons (now named "More actions") and the synced-issues close button have accessible names; decorative icons are hidden from assistive technology; the approval indicator in the workspace header and the on/off dots on the Configuration sub-tabs have text alternatives for screen readers. Remaining gap: the dashboard pie chart has no text alternative in the same view (a count table exists only as a separate gadget setting). |
| 1.2.1 Audio-only and Video-only (Prerecorded) | Not Applicable | Hooq contains no audio or video content. |
| 1.2.2 Captions (Prerecorded) | Not Applicable | No audio or video content. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) | Not Applicable | No audio or video content. |
| 1.3.1 Info and Relationships | Partially Supports | Data tables use real table markup with header cells and UI Kit DynamicTable with a head row. Section headings are heading elements. Checkboxes carry their label. Changed since 5.126.0 (automated checks only): every form label in the admin app is bound to its control (128 controls checked); the main tab bar and the Configuration sub-tab bar are a tab list with tab panels; the Draft/Published switch is a labelled group of toggle buttons; dialogs have a dialog role and a name; action columns have hidden header text. Remaining gaps: the Failed Syncs list is still a table built from generic rows with a visual header row; some visual headings are plain bold text (dashboard gadget, gadget settings, issue panel) and the admin app has no top-level heading; in the UI Kit surfaces (Global Settings, issue panel, gadget settings) the field labels have not been bound to their fields or verified in a browser, and the public-key field has no label. |
| 1.3.2 Meaningful Sequence | Supports | Reading order follows source order: layout does not reorder content visually and follows document order, and dialogs are rendered as a single block. UI Kit surfaces render Stack/Inline in source order. |
| 1.3.3 Sensory Characteristics | Supports | Instructions name the control or the tab ("Click Refresh Project Details on the Hooq tab"). The three instructions that relied on position alone ("below") have been reworded to name the control; confirmed by an automated check of the wording. |
| 1.4.1 Use of Color | Partially Supports | Every status badge carries its status as text: Hooq state and draft state pills, Sync Health indicator, failed-sync status, panel and gadget Lozenges; the data-readiness dot is accompanied by text; the active tab is marked by an underline as well as colour; feature state in the tab header is text. Changed since 5.126.0: the selected option in the New Hooq mode step is now a radio button with a selected state; the approval dot and the sub-tab on/off dots have text alternatives for screen readers and darker colours. Remaining gaps (for sighted users): the approval state in the workspace header is still shown only by the colour of a dot, and the enabled/disabled state on the Comments, Attachments, Worklogs, Boards and Sprints sub-tab labels is still a coloured dot. |
| 1.4.2 Audio Control | Not Applicable | No audio plays. |
| 2.1.1 Keyboard | Partially Supports | Previously Does Not Support. UI Kit surfaces: all actions are buttons, links, selects and text fields (not exercised with a keyboard). Admin app: the five main workspace tabs and the Configuration sub-tabs are now buttons in a tab list with arrow-key, Home and End movement; the New Hooq mode cards are radio buttons; the synced-issues count is a button; the overview checkbox column that opened a Hooq was removed. Manual check actually run (keyboard only, on a development installation of the same code): the arrow keys moved a visible focus ring along the five main tabs and wrapped from the last to the first, Enter opened each of the other four tabs, and Tab moved on to the next control. Not yet checked by hand: the sub-tabs, the mode cards, Escape on menus, dialogs and the UI Kit surfaces; for those only automated checks of the code exist. Known remaining gap: the exact "Last received/sent" timestamps in the issue panel are in a tooltip around non-focusable text. Rated Partially Supports because the main blocker is fixed and was confirmed by hand, but most of the rest is confirmed by automated checks only. |
| 2.1.2 No Keyboard Trap | Supports | Checked by hand on a development installation, keyboard only. Every dialog that was reached was opened with the keyboard and tabbed through at least 12 times: focus stays inside the dialog, Escape closes it, and the Hooq menus (list header, row, detail header) also close with Escape. The Configuration sub-tab list can be left with Tab. One exception, said plainly: in the Notifications edit dialog, while focus is inside one of the Groups, Users or Project Roles select boxes, Escape does nothing until focus is moved to another control; the Cancel and close buttons still work, so this is not a trap. Not walked through by hand: the Hooqs table and the Troubleshooting filters and table (Tab-out not tested) and the Escape key on the detail header menu. The synced-issues dialog was opened with the mouse and then used by keyboard. The Atlassian-built pages and the Atlassian UI Kit Modal were not part of this check. |
| 2.1.4 Character Key Shortcuts | Not Applicable | Hooq defines no single-character shortcuts; the only key handled is Escape. |
| 2.2.1 Timing Adjustable | Partially Supports | Hooq imposes no session limit of its own; when the host session expires the screens stop refreshing and ask for a reload. The connector code expires after five minutes; this is a security control essential to the pairing handshake and a new code can be generated at any time. Changed since 5.126.0: save confirmations on five configuration tabs now stay for 10 seconds (was 3) and can be dismissed earlier; error messages never time out. Remaining gap: those confirmations still disappear automatically with no way to extend the time. |
| 2.2.2 Pause, Stop, Hide | Partially Supports | Status content refreshes automatically while a tab is visible: overview list every 15 s, workspace header every 10 s, Sync Health every 30 s, data-readiness every 10 s, failed syncs every 30 s, issue panel every 30 s, gadget every 180 s. Refresh pauses only when the browser tab is hidden; no user control pauses it. Changed since 5.126.0: decorative animations (pulsing dots and icon, bouncing icons) stop or run once when the user's system asks for reduced motion (confirmed by an automated check of the style rules, not tested on a device). Without that setting they still run and cannot be paused. Content updates in place, so the rating is Partially Supports. |
| 2.3.1 Three Flashes or Below Threshold | Supports | Nothing flashes; the only repeating animations cycle at 0.5 to 1 Hz and the one-shot shake lasts 0.5 s. |
| 2.4.1 Bypass Blocks | Not Applicable | Hooq is a set of modules embedded in Jira; Jira supplies the page navigation and skip mechanisms. Within Hooq each screen is a single region with section headings. |
| 2.4.2 Page Titled | Supports | The admin app document is titled "Hooq Sync Configuration"; UI Kit modules are titled by Jira from their module titles. |
| 2.4.3 Focus Order | Partially Supports | Within a screen the tab order follows the visual order, and menu items follow their trigger in the source. Changed since 5.126.0 (automated check of the focus logic only): custom dialogs move focus into the dialog when opened, keep Tab inside it, close on Escape and return focus to the control that opened them, and the page behind an open dialog is made inert. A manual keyboard pass has now been done on a development installation (see 2.1.2); it confirmed that focus moves into dialogs and stays inside, but found the focus-return gap described below, so the rating stays Partially Supports. UI Kit Modal is an Atlassian component. Found in the hand check: when a dialog is opened from a row menu (Rename Hooq and Delete Hooq) and then closed, focus is not given back to the control that opened it, because the menu item that opened it has disappeared; the next Tab starts again from the top of the page. Dialogs opened from ordinary buttons (New Hooq, Edit, Preview, the header menu Documentation dialog, synced issues) return focus correctly. The Hooq menu in the list header and the row menu themselves keep focus on their button when closed with Escape. |
| 2.4.4 Link Purpose (In Context) | Supports | Links use the work-item key as text under a column header or row label that states the destination; the attachment-limit link reads "Forge platform limits". Buttons styled as links have explicit text. |
| 2.5.1 Pointer Gestures | Not Applicable | No multipoint or path-based gestures; there is no drag-and-drop in Hooq (no dragging is used). |
| 2.5.2 Pointer Cancellation | Supports | All activation uses click (up event). The only down-event listener closes an open menu when the pointer lands outside it; it performs no action. |
| 2.5.3 Label in Name | Supports | Controls with visible text use that text as their accessible name. Explicit accessible labels are used only on symbol-only controls: "Close" for "x", "Remove <email>" for "x", "Collapse"/"Expand" for triangle glyphs, "More actions" for an ellipsis. Symbol characters used as icons are not text labels under this criterion. |
| 2.5.4 Motion Actuation | Not Applicable | No motion- or device-sensor-based input. |
| 3.1.1 Language of Page | Supports | The admin app document declares its language as English. UI Kit surfaces render inside the Jira document, whose language is set by Jira. |
| 3.2.1 On Focus | Supports | No component reacts to receiving focus: no focus or blur handlers are defined, and the only automatic focus is the name field of the Rename dialog on open. |
| 3.2.2 On Input | Supports | Inputs and selects only update local state until a Save, Create or Send button is pressed. The overview checkbox that used to open a Hooq's workspace and replace the whole screen has been removed; opening a Hooq is now an explicit Open button, and the active Hooq is marked in text. Confirmed by code review and an automated check; not observed with a browser. |
| 3.2.6 Consistent Help | Not Applicable | Hooq screens offer no help mechanism (contact, chat or help page); the "Documentation" menu entry currently shows a placeholder message. |
| 3.3.1 Error Identification | Supports | Detected errors are stated in text next to the action: resync without JQL, rename without name, create failure, connector save/activate/delete failures, empty panel comment or missing attachment, gadget settings without a Hooq, migration without a reference field, invalid import file. Errors in the admin app are now also announced to assistive technology (see 4.1.3). |
| 3.3.2 Labels or Instructions | Partially Supports | Visible labels or captions precede most fields in the admin app, checkboxes have labels, the Global Settings dialogs show a Label above each field, the required Hooq name is marked "(required)". Changed since 5.126.0 (automated check only): every label in the admin app is bound to its control and every select, input, switch and table-row control has an accessible name, including the Troubleshooting filters, the selection checkboxes and the Advanced settings. Remaining gaps: the issue-panel comment box and the attachment picker have only a placeholder, and the public-key box in Global Settings has no label (UI Kit field labelling is not yet done or verified); required project selections in the New Hooq dialog are still not marked as required. |
| 3.3.7 Redundant Entry | Supports | No process asks for the same information twice. When creating a Hooq fails, the dialog reopens with the values already entered; the two-step dialog keeps its values when stepping back. |
| 4.1.2 Name, Role, Value | Partially Supports | Previously Does Not Support. UI Kit surfaces use Atlassian components that expose name, role and state (Button, Select, TextArea, Lozenge, Modal, Popup, DynamicTable). Changed in the admin app since 5.126.0 (confirmed by automated checks of the code, not by a screen reader): workspace tabs and sub-tabs have the tab role and a selected state; New Hooq mode cards are radio buttons; overflow-menu triggers and collapsible card toggles announce their expanded state; dialogs have a dialog role, modal state and a name; form controls, selection checkboxes and enable switches have accessible names; dismiss and close buttons are named. Remaining gaps: field labels in the UI Kit surfaces (issue-panel comment box and attachment picker, Global Settings fields, gadget settings) are not yet bound or verified; the Failed Syncs list has no table roles; and no screen reader has been used to confirm any of the above. |
Table 2: Success criteria, Level AA
| Criterion | Conformance level | Remarks and explanations |
|---|---|---|
| 1.2.4 Captions (Live) | Not Applicable | No audio or video content. |
| 1.2.5 Audio Description (Prerecorded) | Not Applicable | No audio or video content. |
| 1.3.4 Orientation | Supports | No orientation lock and no orientation-specific styling; layouts work in either orientation. |
| 1.3.5 Identify Input Purpose | Not Applicable | No field collects information about the user. The notification e-mail field collects recipient addresses for failure notifications. |
| 1.4.3 Contrast (Minimum) | Supports | Previously Partially Supports. The colours that failed in 5.126.0 were changed (orange, green and caption text tones; the undefined colour variables now have values). An automated check reads the real style sheet and computes the WCAG ratio for 48 listed colour pairs; all pass 4.5:1 for text, for example caption text on the tinted surfaces 4.8:1 or more, RUNNING and Published badges 6.5:1, PAUSED and Draft badges 6.9:1. UI Kit surfaces use Atlassian design tokens. The ratios are computed from the style sheet; a scan of the rendered pages has not been run, and the Atlassian components were not measured. |
| 1.4.4 Resize Text | Supports | Tested on a development installation with an automated browser. A real 200 % browser zoom was not used: 200 % was emulated by setting the viewport to 640 CSS px, which is what a 1280 px window shows at 200 % (layout does not depend on the screen's pixel density). On 15 of the 17 admin screens and in the issue panel there was no loss of content or function. Three screens need sideways scrolling inside the app frame but stay fully reachable: the Hooqs list (a data table, 573 px against a 560 px frame), the Troubleshooting filter row (817 px) and Advanced (589 px). Font sizes are fixed pixel values that scale with browser zoom and no text container has a fixed height except scrolling regions. Text-only zoom (without layout zoom) was not tested. |
| 1.4.5 Images of Text | Supports | The only image of text is the Hooq logotype, which is exempt as a logo; all other text is rendered text. |
| 1.4.10 Reflow | Does Not Support | Tested on a development installation with an automated browser set to a true 320 CSS px wide viewport (not a constrained frame). All 17 admin screens (the Hooqs list, the Hooq tab, the five main tabs and the 11 Configuration sub-tabs) need sideways scrolling inside the app frame. The widest content: Troubleshooting 817 px, Advanced 619 px, the Hooqs list 573 px, Notifications 449 px, the rest 386 to 429 px, and Migration 264 px, against a frame width of 240 px. Jira itself insets the app frame by 40 px on each side, so a 320 px viewport leaves the app 240 px; that inset is Jira's and is noted here, but the content is still wider than the frame. Data tables are exempt from this criterion, but the header buttons (Back to Hooq overview, Stop Hooq and the others) run past the edge of the frame and are clipped, the status label is cut down to two letters, and the Configuration view switch is clipped. In the issue panel, the panel is 280 px wide and starts about 68 px in, so its right edge is past the viewport; values are cut off (for example an issue key, the assignee and the attachment count) and there is no scroll. At a 640 px viewport the panel and the admin screens fit, apart from the three screens listed under 1.4.4. |
| 1.4.11 Non-text Contrast | Partially Supports | Changed since 5.126.0 (ratios computed by an automated check): the keyboard focus indicator is a solid 2 px #0052CC line, 6.8:1 on the page and 6.4:1 on the muted surface (was 1.7:1); the switch off-state track is 5.3:1; approval dots 7.3:1 or more; feature on/off dots meet 3:1. Passing as before: active tab underline and selected-card border 6.8:1; switch on-state track 4.6:1. Remaining gaps: text-field borders (#DFE1E6) are still about 1.3:1 against white; data-readiness dots 1.5 to 2.3:1, mitigated by the adjacent text. UI Kit controls use Atlassian defaults. |
| 1.4.12 Text Spacing | Supports | Supports on the surfaces that were tested. The WCAG text-spacing values (line height 1.5, paragraph spacing 2 times the font size, letter spacing 0.12 times and word spacing 0.16 times the font size) were applied by script to a development installation, and the number of clipped boxes was compared before and after on all 17 admin screens, the issue panel and the synced-issues dialog. Nothing new was clipped or lost; no element was found on these screens that cuts text off with an ellipsis (an earlier code review had listed two such texts; they could not be located on the tested screens, so where they are is not confirmed). Other surfaces were not evaluated: the dashboard gadget and its settings, the Get Started, Global Settings and Hooqs admin pages built from Atlassian components, and the other dialogs. Atlassian-rendered components were not inspected. |
| 1.4.13 Content on Hover or Focus | Partially Supports | Tested in the issue panel on a development installation. The only author-controlled hover content is the UI Kit tooltip, for example the one on the Resync button. It appears on pointer hover and on keyboard focus, stays visible when the pointer moves onto it (hoverable) and was still visible after 6 seconds (persistent). It is not dismissed by Escape: Escape was pressed while hovering and while the button had focus, and the tooltip stayed. That tooltip is an Atlassian component, so the gap is most likely in the platform and may not be fixable in Hooq. The other tooltips in the admin app are native browser tooltips (the title attribute); they are exempt but are not shown on keyboard focus and cannot reliably be dismissed with Escape. They were not tested. |
| 2.4.5 Multiple Ways | Not Applicable | Hooq is a configuration module within Jira, reached through Jira's own navigation; its screens are steps of one process. |
| 2.4.6 Headings and Labels | Partially Supports | Headings describe their section ("Hooq", "Configuration", "Notifications", "Troubleshooting", "Work Types", "Field Mappings", "Workflows", "Advanced", "Sync Health", "Global Settings", "Welcome to Hooq"). Changed since 5.126.0 (automated check): the overflow menus are named "More actions"; action columns have hidden header text; the two "Mapping Type" controls in the field-mapping dialogs are still shown, but each is now named to say it edits the same setting. Remaining gaps: in the New Hooq dialog "Your Instance" labels both a section and a project selector; some visual headings are plain text (see 1.3.1). |
| 2.4.7 Focus Visible | Partially Supports | Custom buttons, links, tabs and other focusable elements show a solid 2 px #0052CC focus ring (6.8:1 on the page; the rule is checked automatically); native inputs, checkboxes, selects and textareas keep the browser focus ring; Atlassian components provide their own focus styles. Manual check actually run (development installation of the same code): a visible blue focus ring moved along the main tabs and landed on the next button. Tabs and mode cards can now receive focus. Not yet checked by hand: sub-tabs, dialogs, select menus and the UI Kit surfaces. No known defect remains for the admin app, but the rating stays Partially Supports until those are checked. |
| 2.4.11 Focus Not Obscured (Minimum) | Partially Supports | No sticky headers, footers or banners cover content. Changed since 5.126.0 (automated check only): while a custom dialog is open the page behind it is inert, so focus cannot move to controls hidden by the backdrop. A manual keyboard pass has now been done on a development installation (see 2.1.2); it confirmed that focus moves into dialogs and stays inside, but found the focus-return gap described below, so the rating stays Partially Supports. |
| 2.5.7 Dragging Movements | Not Applicable | No functionality uses dragging (no drag handlers in the interface); ordering and mapping are done with selects and buttons. |
| 2.5.8 Target Size (Minimum) | Supports | Measured on screen in a development installation (about plus or minus 2 px). Every measured target is at least 24 px or meets the spacing exception. The smallest are the table checkboxes at 16 by 16 px (Troubleshooting select-all and row checkboxes, Notifications Enabled), with at least 35 px between them and the nearest other target; the e-mail remove button is 20 by 32 px with 12 px to the nearest target; the message dismiss button is 22 by 32 px with about 75 px to the nearest target. The synced-issues button in the list is 93 by 21 px with about 65 px to the nearest target. All other targets measured were at least 32 px high: the synced-issues dialog close button 41 by 32 px, the dialog Cancel and Save buttons, and in the issue panel Resync 73 by 32 px and Comment 89 by 32 px. Native browser controls and Atlassian-rendered components were not measured separately. |
| 3.1.2 Language of Parts | Supports | All interface text is English; user content (names, keys, messages) is displayed as entered. No passages in another language are authored by Hooq. |
| 3.2.3 Consistent Navigation | Supports | The workspace tab bar and the Configuration sub-tab bar keep a fixed order; the header actions and overflow menu appear in the same place on every workspace screen. |
| 3.2.4 Consistent Identification | Supports | Repeated functions use the same names and controls across screens: "Refresh", "Save ...", "Cancel", "Delete", "Edit", the "..." overflow menu, inline error and success messages, the enable switch pattern. |
| 3.3.3 Error Suggestion | Supports | Error messages state the correction: "Provide at least one JQL filter.", "Hooq name is required.", "Select a Hooq before saving dashboard settings.", "Comment cannot be empty." and "Select an issue attachment before sending.", "Please select a reference field.", "Invalid JSON file.", "Public key is unavailable right now. Click Refresh to retry.". |
| 3.3.4 Error Prevention (Legal, Financial, Data) | Partially Supports | Deleting a connector requires confirmation in a dialog. Changed since 5.126.0: "Delete Hooq" in the overview row menu now opens a confirmation dialog that names the Hooq, says it cannot be undone and has Cancel as the default focus (confirmed by an automated check and by opening the dialog by hand: Cancel has the focus). Remaining gaps: "Disable Hooq", "Discard Draft", "Clear All Errors" and "Clear Logs" still act immediately. Removing mapping rows is reversible until Save. Confirmed by hand on a development installation: "Disable Hooq" in the row menu stops a running Hooq at once, with no confirmation (it can be started again with Start Hooq). Delete Hooq does ask first, with Cancel as the default. |
| 3.3.8 Accessible Authentication (Minimum) | Not Applicable | Hooq has no authentication step; users are signed in by Jira. |
| 4.1.3 Status Messages | Partially Supports | Previously Does Not Support. In the admin app, error messages are now announced as alerts and results (saves, loading, connection feedback) as polite status messages; confirmed by an automated check of the code, not heard with a screen reader. In the UI Kit surfaces (issue panel, dashboard gadget, Get Started, Global Settings and Hooqs pages) results are still not announced, because the Atlassian components Hooq uses (SectionMessage, Text, Box) offer no way to mark a message as a live region. The native alert dialogs for create and delete failures are announced. |
Table 3: Success criteria, Level AAA
Not evaluated.
Summary of ratings
| Conformance level | Level A (31 criteria) | Level AA (24 criteria) |
|---|---|---|
| Supports | 13 | 10 |
| Partially Supports | 9 | 7 |
| Does Not Support | 0 | 1 |
| Not Applicable | 9 | 6 |
| Not Evaluated | 0 | 0 |
What changed since the previous review (version 5.126.0)
- Keyboard (2.1.1): Does Not Support to Partially Supports. The workspace tabs, sub-tabs, mode cards and synced-issues count are real controls; the arrow keys, Enter and Tab on the main tabs were confirmed by hand, the rest by automated checks only.
- Name, Role, Value (4.1.2): Does Not Support to Partially Supports. Names, roles and states were added in the admin pages (automated checks); field labels in the Atlassian-built pages and the Failed Syncs list are still open.
- Status Messages (4.1.3): Does Not Support to Partially Supports. Errors and results in the admin pages are announced (automated check, not heard with a screen reader); the Atlassian-built pages cannot announce them.
- Contrast (1.4.3): Partially Supports to Supports. The failing colours were changed and 48 colour pairs computed from the style sheet all pass; a scan of the rendered pages has not been run.
- Sensory Characteristics (1.3.3): Partially Supports to Supports. Three instructions that relied on position were reworded.
- On Input (3.2.2): Partially Supports to Supports. The checkbox that opened a Hooq and replaced the screen was removed.
- No Keyboard Trap (2.1.2): Supports in the previous review (from code), Not Evaluated while the new dialog code was untested, and Supports again now. A hand check with the keyboard on a development installation confirmed that no dialog or menu keeps focus, with one plain exception (Escape is ignored in the Notifications edit dialog while a select box has focus).
- Reflow (1.4.10): Not Evaluated in the previous review, Partially Supports in the 3 October version of this report, now Does Not Support. A true 320 px wide viewport test showed that all 17 admin screens need sideways scrolling inside the app frame and that the issue panel is wider than the viewport.
- Resize Text (1.4.4), Text Spacing (1.4.12), Target Size (2.5.8): Not Evaluated (or Partially Supports for Target Size) to Supports, after the automated-browser checks described above. Resize Text rests on an emulated 200 % (640 px viewport), not a real browser zoom.
- Content on Hover or Focus (1.4.13): Not Evaluated to Partially Supports. The tooltip is hoverable, persistent and shown on keyboard focus, but Escape does not dismiss it.
Legal disclaimer: this report describes the product version named above as reviewed on the report date. It is a self-assessment; no third-party audit and no screen-reader testing has been performed. The manual and automated-browser testing is the keyboard, narrow-width, enlarged-text, text-spacing, tooltip and target-size checking described under evaluation methods.