- 19 Jan, 2021 1 commit
-
-
Joanmarie Diggs authored
When authors hide text offscreen so that only screen readers will find them and present them, they think they are being helpful. Unfortunately, their techniques by side effect can break what we get for the accessible text (e.g. asking for a line at offset results in only a single char or word). Thus we have to sanity check all text in order to work around this. Normally this is not a performance problem because we can bail after checking the first line. But in a giant text object whose contents consist almost entirely of embedded object chars, we can get quite laggy. Therefore, if the accessible text is more than 30% embedded object chars, bail on the lines-are-single-words sanity check.
-
- 18 Jan, 2021 1 commit
-
-
Jordi Mas authored
-
- 13 Jan, 2021 2 commits
-
-
Matej Urbančič authored
-
Daniel Mustieles García authored
-
- 11 Jan, 2021 3 commits
-
-
Marek Černocký authored
-
Attila Hammer authored
-
Attila Hammer authored
-
- 08 Jan, 2021 6 commits
-
-
Joanmarie Diggs authored
And include workarounds for people finding that commented out code and reporting it as a bug, rather than using the more recent and reliable methods for interrupting speech.
-
Joanmarie Diggs authored
The code in speech.py is very pro-interruption. It gets called by the scripts for multiple-utterance presentation. Without some significant changes, we're in danger of cutting off all but the last utterance. :( This reverts commit ce033c08.
-
Joanmarie Diggs authored
-
Timo Jyrinki authored
-
Joanmarie Diggs authored
speak() and speakUtterances() had the use of the interrupt argument commented out back in 2007 due to unspecified issues. In 2013, we enabled this and then immediately re-disabled it due to regressions. Most of the code handles interruption via explicitly calling the script's presentationInterrupt method which calls speech.stop, which causes _cancel to be called in speechdispatcher factory. That said, there may be downstream/external scripts/functionality that for some reason isn't calling presentationInterrupt or stop. And having this option in place but non functioning seems silly. So we'll re-enable it but set the default value to False in the hopes that we minimize the number of regressions that may be unexpectedly introduced by this change.
-
Joanmarie Diggs authored
Sometimes web pages auto-focus a widget after page load. If we're doing a SayAll of that page at the time this occurs, we don't want to leave browse mode because it can impact what and how we present things as well as put the user in an state they don't expect.
-
- 07 Jan, 2021 3 commits
-
-
Joanmarie Diggs authored
If we haven't found a preferred table, we still need a full path for the fallback table. #150.
-
Joanmarie Diggs authored
* Match the active locale * Don't prefer tables like interline and mathtext * Prefer g1 then g2 then comp6 then comp8 (here the goal is maximize saneness for a brand-new install for a user whose braille level is unknown and might be minimal) Note: This won't impact existing configurations. Fixes #150.
-
Joanmarie Diggs authored
Don't read the full row if the last input event was a mouse button event. We always generate the full line (i.e. each cell in the row) when the caret moves due to a mouse click. If we think we should read the full row for each cell in that row, we'll be extremely chatty and also fail to present the column headers.
-
- 06 Jan, 2021 8 commits
-
-
Fran Dieguez authored
-
Daniel W. Steinbrook authored
Increase consistency between load/remove profile dialogs. Fixes #146
-
Joanmarie Diggs authored
This addresses an edge case: We're in SayAll, a caret navigation command is given which interrupts SayAll, and we happen to land in an empty text element (e.g. a paragraph) as a consequence of that caret navigation command. In this particular case, we should say "blank" but we weren't doing so because we only do that "blank" fallback when we are not in SayAll. (Interrupted SayAll is treated as in SayAll due to the fast-forward and rewind commands.) To address this edge case, add an optional argument to inSayAll() that allows us to treat interrupted SayAll as not being in SayAll. Then use that for the "blank" fallback for web content.
-
Joanmarie Diggs authored
There shouldn't be useless empty elements at the top of a document. But authors, along with Thunderbird.... Therefore when seeking the first context in the document (e.g. when pressing Ctrl+Home), start with the first child that isn't a useless empty element.
-
Joanmarie Diggs authored
In <pre> and <code> blank lines are presumably there for a reason. Thus skipping over them is a bug.
-
Joanmarie Diggs authored
For most accessible objects, we attempt to generate lots of things (e.g. role, relevant states, displayed text, selection, etc.) and by default we separate these pieces of information by pauses. In some cases (e.g. an empty paragraph) it is possible to generate results consisting solely of pauses. We don't want to treat that as actual results because it can cause other logic (e.g. saying "blank") to not kick in and lead to our speaking nothing.
-
Joanmarie Diggs authored
We were losing track that the last command was a caret-navigation command when Ctrl was released after using Ctrl+Home. As a result, when the browser emits caret-moved and focus-changed events we triggered, we process them rather than ignoring them as caused by us.
-
Joanmarie Diggs authored
Unfortunately, empty anchors can appear in the accessibility tree. If caret navigation causes us to land on one, there's nothing to present. Therefore look for and move to the first presentable thing after the empty anchor.
-
- 04 Jan, 2021 2 commits
-
-
Joanmarie Diggs authored
* Try to get to the bottom of Orca not starting due to timeout * Try to identify why braille contraction is not happening
-
Aurimas Černius authored
-
- 03 Jan, 2021 1 commit
-
-
Jordi Mas authored
-
- 22 Dec, 2020 3 commits
-
-
Joanmarie Diggs authored
On some pages, the content we're navigating in is contained in the document itself (as opposed to a child element). In those cases, we don't want to speak the document title when the caret first returns to the body as a consequence of using caret navigation.
-
Joanmarie Diggs authored
There were special occasions (such as headings) when caret moved events caused the entire object to be presented when clicking with the physical mouse. This was not intentional. Move mouse-button handling to the top of the logic where we determine what to present when the locusOfFocus changes. In addition, explicitly set the prior object to the old focus for mouse- button-triggered caret-moved events. This should ensure we present roles when initially clicking into a new element.
-
Christian Kirbach authored
-
- 19 Dec, 2020 1 commit
-
-
Jordi Mas authored
-
- 16 Dec, 2020 5 commits
-
-
Anders Jonsson authored
-
Yuri Chornoivan authored
-
Florentina Mușat authored
-
Joanmarie Diggs authored
Quirks in web sites and web browsers are tricky.... * If the children-changed event is our current object, dump cache and also the context because all bets are off regarding whether or not our current location is stale. * If the children-changed event is an ancestor of our current object, dump cache but preserve the context because something around us has changed, but our present location should still be valid. Plus subsequent sanity checks should trigger us to update things if our present location isn't valid after all. * Otherwise, something elsewhere has changed so don't dump the cache. Also add more debugging to get to the bottom of remaining quirks.
-
Joanmarie Diggs authored
-
- 15 Dec, 2020 4 commits
-
-
Joanmarie Diggs authored
Hopefully this will work around whatever bugs we're seeing in Firefox's table and text support that cause us to not be able to correctly locate our position.
-
Joanmarie Diggs authored
-
Joanmarie Diggs authored
-
Joanmarie Diggs authored
We now dump all of our cache when children-changed events are emitted. This ensures we are not working with a stale tree (which can cause us to get stuck and/or skip over content). Unfortunately, clearing the context has exposed bugs in browsers. It should be safe to preserve the context by default so we do not have to search for the current location after a children-changed event that hasn't destroyed the current location's accessible object.
-