Consider adding an attribute for table-cell formulas

[joanmarie]

Some screen readers announce "has formula" both in native application tables (e.g. LibreOffice Calc and Writer) and in web applications (e.g. Google Sheets).

In native applications, the screen reader is able to identify the presence and contents of the formula through its exposure in the accessibility tree. The user, in response to hearing "has formula", can then use the screen reader's command to obtain that formula.

In web applications (e.g. Google Sheets) that support accessible formulas, the "has formula" announcement comes via live regions. But the screen reader command to read the current formula subsequently fails, which can be confusing to the user who then has to figure out how to access the formula's contents for that particular web app.

I'd like the ARIA Working Group to consider adding an attribute for table-cell formulas so that screen readers can provide a consistent user experience.

Thanks in advance!

[jnurthen]

@cookiecrook @smhigley @spectranaut to look to see how this is mapped in native applications

[jnurthen]

Please re-add agenda once we know what native implementations do @cookiecrook @smhigley @spectranaut

[css-meeting-bot]

The ARIA Working Group just discussed Consider adding an attribute for table-cell formulas, and agreed to the following:

• RESOLUTION: Sara will propose the specific text change in the issue

The full IRC log of that discussion

<Zakim> agendum 6 -- -> Consider adding an attribute for table-cell formulas https://github.com//issues/2709 -- taken up [from agendabot]
<Daniel> scribe-
<Jacques> jamesn: we asked three implementors how this was going to work but haven't heard back.
<Jacques> aardrian: lets skip this one.
<Jacques> zakim, next item
<Zakim> agendum 7 -- If time, next steps for aria-actions: -> aria-actions: handling focus when actions are synthetically triggered https://github.com//issues/2691 -- taken up
<Zakim> ... [from agendabot]
<Daniel> rrsagent, draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2026/02/05-aria-minutes.html Daniel
<Jacques> sarah: I wanted to check - the tables added are script heavy and focused on aria-activedescendant
<Jacques> Matt: in the first use case, the APG example cannot do what is expected, but in the other use cases that are related to keyboard and mouse they do what is expected
<Jacques> Matt: I rewrote all of the tables on James Craig's feedback to be clear on focus vs active descendant.
<Jacques> sarah: this is good, but this isn't focused on what the browser does
<Jacques> sarah: this is fine for this example, but this is a very specific example.
<Jacques> sarah: this isn't talking about the difference of what the browser would do
<Jacques> Matt: we want to make sure this works in both the case where you do and don't use activedescendant. These are real world examples we expect to work.
<Jacques> sarah: Is the conclusion that the browser does not set focus when you use the actions rotor
<Jacques> Matt: that is correct
<Daniel> +1 to JamesN, we should really keep these arguments for when they ask for rationale
<Jacques> jamesn: we should prepare ourselves for feedback from wider review, make sure we have a good response for why this is OK. I suspect they will flag this.
<Jacques> jcraig: the js event model gives away more about users than anything this is doing.
<Daniel> q?
<Jacques> jcraig: I would object to the browser doing anything different than it normally would. Say the browser is synthesizing a mouse click, by default the focus will move. Doing what browser does today will be the only way to not add an additional detection vector.
<Jacques> jcraig: we could say that AT should consider if an automatic focus change should bring AT focus along with it.
<Daniel> q?
<Jacques> Matt: if the AT says activate action X and anything more than that happens, then that breaks.
<sarah> q+
<Jacques> Matt: js should continue to influence focus as it does today, but doing an action from the ATs shouldn't be seen as a regular click event.
<Jacques> jcraig: When you trigger an accessibility press, cascade of event, mouse down, mouse up, events, if the element is focusable then by default focus will move to the element. this is the normal browser behavior, so we shouldn't let actions from an AT avoid this normal flow of events.
<Jacques> sarah: I don't see how preventing focus moving could cause issues with most controls. I do see how this could be used as an AT detection vector, but I don't think this is a new concern.
<Jacques> sarah: eventing and focus differences between AT and non AT are already present.
<Jacques> sarah: This is the same thing, but only happens with aria-actions, as opposed to what already exists.
<Jacques> sarah: one of the major use cases is composit widgets, if dom focus moves then that could already break in some instances.
<Jacques> sarah: if focus moves from a list to a button when an action is used, a user wouldn't expect focus to move, so when they hit down it wouldn't work as they would expect.
<Jacques> jcraig: we should get into more details on a spec PR so we can discuss deeper.
<Jacques> sarah: I can make a PR to my PR branch to discuss this on.
<Jacques> jcraig: Maybe make a new PR to replace the original, if the original is causing issues on Github.
<Jacques> sarah: I could put the proposed wording change on the issue.
<Jacques> jcraig: lets discuss the specific wording on the issue.
<Jacques> RESOLUTION: Sara will propose the specific text change in the issue
<Jacques> sarah: If screen reader focus hasn't moved but dom focus does, it could cause issues.
<Jacques> jcraig: If star is used in gmail, then there could be issues.
<Jacques> jcraig: If I hit star and focus was moved to star, then arrow keys might not do anything, but this would be for all users.
<Jacques> Matt: That might not be how the APG example works. If you click the move-up button, after clicking it focus moves to it.
<Jacques> Matt: that one can be complicated due to activedescendant
<Jacques> jcraig: All the places this is going to be used are reasonably complicated web applications, where subsequent actions are reasonably handled.
<Jacques> sarah: We aren't expecting someone to click on a button with the mouse and then use arrow keys and expect it to work. This could break many things I've seen.
<Daniel> rrsagent, draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2026/02/05-aria-minutes.html Daniel
<Jacques> zakim, end meeting