Accessibility
Last updated 3 November 2026
Every Lineset app is drawn inside Jira with Atlassian’s own components, so it follows Jira’s keyboard, focus and screen reader behaviour. This page says what we build on top of that, what is not there yet, and how to tell us when something does not work for you.
In the apps
- Keyboard. Every button, chip, menu and link is reached with Tab and pressed with Enter. A filter chip’s menu opens, picks and closes from the keyboard, and keeps your place while the page draws again.
- Names a screen reader says. A button is named by its words, never by its icon; Logline’s two period arrows, which show only an icon, are named “Previous period” and “Next period”. A filter that is on or off says “On” or “Off” before its words, and a chip that holds a choice names it, such as “Status: Done”. Tables carry a name, such as “Timesheet: Team week, 28 Sep – 4 Oct”. A row’s chevron says whether it opens or closes.
- Reasons in words. Recalculate says why it cannot be pressed yet on the page, “Recalculate in 1 min”, not only in a tooltip a keyboard never reaches.
- Not by colour alone. Blockline writes every level as a word: OK, Watch, At risk, Blocked. Sumline names every warning in words in the work item panel, the Details column and the downloads. Logline’s coloured lozenges and bars carry their figure. Dueline writes every report’s state as words: Late, Due soon, Due, Waiting or Sent. Workline writes a week’s load as hours and their share in a lozenge, and says Off, Late, Booked, Tentative and Placeholder in words.
- Tap targets. A figure that opens something, such as an hours figure in Logline’s timesheet, a cell in Blockline’s team matrix or a person’s unscheduled hours in Workline’s plan, is a target of at least 24 by 24 pixels, as WCAG 2.2 asks.
- Blockline’s dependency map. Every box on the map is a link that names its level and date: Tab moves from box to box and Enter opens the work item.
- Light or dark. The apps take Jira’s own colours, so they follow the theme you choose in Jira.
- Three screens. Every page is designed for a 1920 and a 1440 pixel screen and a 390 pixel phone, and looked at on all three. A row of controls wraps onto the next line instead of running off the screen.
On these websites
Every page reads with JavaScript off, starts with a link that skips to its content, and gives every screenshot a text alternative. A screenshot too wide for a phone scrolls sideways there, in a frame a keyboard can reach and a screen reader names; on a larger screen it fits. A row of pills over a screenshot is a group of radio buttons named for what it picks, moved with the arrow keys. A guide or a docs page names its place in a trail above its title.
Not there yet
- Wide figure grids on a phone. The tables of figures, Sumline’s roll-up tables, Logline’s timesheet, Blockline’s team matrix and Workline’s plan, are wider than the screen and scroll sideways in their own box, as does Logline’s list of saved reports. Workline’s other tables, in its work item panel and its dialogs, stay tables with their name. Every other table folds into a card per row on a phone, Workline’s gadget among them, and a folded table does not carry its name there.
- A chosen chip. A filter chip that is on is drawn pressed, but Jira’s button does not tell a screen reader so; the “On” before its words, or the choice it names, carries it instead.
- A control that does not apply. A filter, a switch or a menu choice that cannot apply to what is on screen is not shown, so there is no greyed control whose reason a keyboard would not hear. A greyed button other than Recalculate, such as Save before a form is complete, says why on hover only, which a keyboard that cannot reach it does not hear.
- Sumline’s warnings in a table. A row with two or more warnings shows one lozenge, such as “2 warnings”, and names each only when you point at it; a keyboard or a screen reader gets “2 warnings” alone. The work item panel, the Details column and the downloads name each.
- Logline’s marks. The coloured lozenge after a figure, such as a work item’s share of its estimate, the billable share or a budget’s share used, a week’s load in Workline, the timesheet’s marks under what is expected, and the bars on one scale say what the colour means only when you point at them; a keyboard or a screen reader gets the figure alone, such as “-3h”, “62%” or “130%”, and on Workline’s weeks not the hours it is planned against, nor the hours a week with nothing in it has free.
- Notes on a figure. In a work item’s Details column, what a figure leaves out, such as an estimate counted once or time that is not billable, is said on hover only; so is the time that is not billable or has no rate, on the billable share of Logline’s report Total row and its dashboard gadget, and the hours with no cost rate on the Total row’s cost, and a budget’s pace on its share used; so is where the dates came from, in Workline’s Details column and on its plan’s cells, and what Total and Unscheduled count, on their headings. A keyboard or a screen reader gets the figure alone. The work item panel says the same in a grey line under the figures.
- Logline’s PDF timesheet. It is an untagged PDF: a screen reader reads its words in order, without the table’s structure. Excel, from the Download menu, holds the same lines.
- Jira’s own parts. The cross that removes a chosen value from a multi-select is Atlassian’s, 16 pixels wide, and an app cannot resize it. Backspace in the field removes the value too.
What we hold ourselves to
The target is WCAG 2.2 at level AA. Every page of every app is checked with axe in the UI checks that run before each release, against WCAG 2.1 A and AA on a desktop screen; the WCAG 2.2 rules, such as target size, are held by tests in the code. Each surface is walked with the keyboard and looked at on the three screens. These websites are not checked by axe yet, and a pass with a screen reader is not yet part of every release. There is no VPAT yet. This page is checked against the apps every month and with each release, and says when it last was: 3 November 2026.
Tell us
If something in an app or on these websites does not work with your keyboard, screen reader, zoom or phone, tell us through our support site or by email at support@lineset.dev: what you were doing, where, and with which browser and assistive technology. We answer within one business day, Monday to Friday.