GitLab

While "placeholder-text" usage predates aria-placeholder, some user agent
implementors would prefer to expose placeholder text using "placeholder"
because doing so is consistent with the convention used for other ARIA
properties. So check for both.

* When the command to speak the status bar is given, also generate
  and display braille
* When a status bar claims focus (which it now can in, at least,
  VSCode) present the status bar items in speech and braille
* Generate end-of-line indicators for braille labels, if the user
  has that setting enabled. This causes status bar labels in apps
  like LibreOffice Writer to not be a bunch of disjointed text.
  And we normally display the end-of-line indicator for text
  objects anyway.
* Harmonize link presentation between speech and braille. This
  not only makes presentation consistent, but it eliminates things
  like non-printable / private-use-area characters from showing
  up in the braille of the status bar of (at least) VSCode.

In the case of Chromium, we were announcing the role, but not checking
for text content; in the case of Firefox, we were finding a child of the
separator with text but not then presenting the ancestor separator. This
fix causes us to handle both cases.

Also, don't present values for non-focused separators. Non-focusable
separators are not supposed to implement the value interface. But if an
author slaps a tabindex value of -1 on them, then user agents seem to
treat them as focusable and expose the value interface on them, complete
with default values which are likely useless noise given the object is
not serving as a widget.

Checkable menu items should have STATE_CHECKABLE and/or the role of
ROLE_CHECK_MENU_ITEM. Apparently this is not always the case for Qt
apps. This workaround should cause Orca to announce the checked state
when present, but not announce "not checked." In order for the latter
to occur, Qt apps should fix the aforementioned bug.

Some comboboxes have a name based on its value rather than on the
associated label. So don't check for that condition in the generator
and instead try to identify when the name is not based on the value
in the script utilities.

* Move calculation of combobox value out of generator for name and
  into script utility
* Handle calculation of combobox value in generator for value
* Also check for valuetext object attribute in web content to save
  on calculation time
* Make braille generation more consistent with speech generation
* Have displayedText get strings even for objects we normally wish
  to treat as textless (such as select-only comboboxes)

We should not be taking static-text leaf nodes into account when
looking for the selected item in a combo box. That value will get
presented as part of the displayed text.

List items in list boxes might have state checkable. We need to look for
that condition and present it if found.

The footnote role was added to AT-SPI2 in version 2.26, and Orca's
minimum required version of AT-SPI2 is 2.26. Thus there is no longer
a need for a special role in Orca.

The row header will already be presented as part of the row contents

Sadly we're having to check object attributes more and more for web
content and applications. All those calls to getAttributes() adds up.
Therefore cache them. Testing will be needed to ensure our cached
attributes are not stale, but so far this change seems to be a win
for performance.

We're seeing instances where the name is a subset of the label:
  * label: "Leading space:" name: "Leading space"
  * name: "Stacking order (Z)" name: "Stacking order"

In this instance, when generating the label and name for the widget,
we don't want to append the name to the label. Therefore if the label
text starts with the name text, don't append the name.

1. Don't even fall back on displayed text for the name. When and if
   that proves necessary, we can fix it either in the formatting
   string or make a role-specific tweak in the generator(s)

2. Fix presentation of spin button, presenting the displayed text
   and falling back on the value reported by AtspiValue

Long, long ago the decision was made to prefer the displayedText over the
accessible name. To be honest, I'm not sure why. I've subsequently not
changed that for fear of breaking something unexpected. But bugs keep
coming up because of this old decision. We'll fix them based on reports
before this is included in stable.

When generating the full contents of a row, not all properties apply
to all cells in the same row (e.g. the pre-calculated-for-performance)
string. Remove these before generation so we don't get bogus results.

Chromium used to expose list item markers to us as static text leaf
nodes; now they appear in a container. This makes it possible to
simplify our support, but we also need to eliminate presentation of
the new panel role we're seeing.

Also improve logic regarding what is a list item marker so we do
not double-present text in an inline list.

* Announce when entering and exiting details container via caret
  navigation. When entering, announce the name and type of object
  the details apply to.
* Announce the name and type of object when an object has details.

Notes:
* This will not be presented if the verbosity is set to brief.
* At the present time, no filtering of obvious or default types is
  taking place. (Example: The default popup of an ARIA combo box is
  "listbox". Rather than filtering it out, Orca will present it.
* The information is being tacked on to the very end of presentation
  so it can be interrupted by users who don't find it meaningful.
* What gets spoken when is subject to change based on user feedback.

List item markers are not exposed in the list item text like they are
in other user agents. Therefore we have to add their content to what
gets presented.

The table interface may reflect the physical table rather than the
conceptual table described by the author.