Users can open a column menu with just the keyboard, using the CTRL and ENTER keys.
The issue I ran into is users are not notified how to open the column menu with just the keyboard. If the user uses an accessibility application such as NVDA, there is no aria-label or aria-description to notify the user how to open it with the keyboard. Is this an ADA defect?
Note that I added an aria-description myself and that resolved the issue for column headers that don't have the header checkbox. If the column header has a header checkbox, the aria-describedby prevents the aria-description and aria-label from being read.
The aria-describedby: ag-29-input on the columnheader div doesn't appear to do anything and is also on the input for the checkbox. Setting aria-describedby to an empty string on the column header fixes the issue where aria-describedby: ag-29-input prevents aria-description and aria-label from being read on NVDA.
How does a sighted user know to press Ctrl+Enter? Are there any instructions for them?
I looked up some ag-grid examples on https://codesandbox.io/examples/package/ag-grid-react (because I wasn't familiar with it) and I ran the "AG Grid React with Key-Value Data" demo. The columns in the table had an aria-description of "Press CTRL ENTER to open column menu."
<div class="ag-header-cell ag-focus-managed" role="columnheader" tabindex="-1" aria-colindex="3" col-id="mealTime" aria-description="Press CTRL ENTER to open column menu.">
So the screen reader user will actually have an advantage over the sighted user because they'll hear the keyboard shortcut instructions. The sighted user won't have any instructions regarding the keyboard shortcuts.
I'm not sure if the person that created that demo added aria-description or if it's built into the ag-grid.
Note that aria-description isn't official yet. It's still in the AIRA 1.3 "Editor's Draft" spec. ARIA 1.1 is the current official spec and ARIA 1.2 is in the "Candidate Recommendation" phase. So I was surprised that the aria-description example worked with NVDA.
In any event, both sighted keyboard users and low vision or blind screen reader users both should be notified about the keyboard shortcut. If the user cannot navigate to the column header and open the menu, whether via a shortcut key or some other keypress, then yes, it would be an ADA issue. It would fail WCAG 2.1.1 Keyboard.
Related
How to click a button when the frame is highlighted after SHIFT+TAB on mac?
Is this not supported in the OSX app as part of accessibility/screen reader feature in MS Teams and description of how to navigate in a view?
I can't figure out i.e. how to click Admit all or Mute all.
FYI - I'm writing applescript to press the required keys sequences accordingly.
EDIT: FYI - the web client supports selecting the button, I have to use the desktop app though for other features.
I tested the desktop version of Teams (1.4.00.26376) on Windows 10; similarly to the OP I also found I couldn't access the 'Mute All' button when focus was on the 'Attendees/In this meeting' accordion panel. But, I could access the 'Mute All' button when I used the Applications Key (or Shift F10) a context menu appeared with the 'Mute All' option and I could access it with the keyboard.
Just as the title says.
I cant find ANYTHING for this particular usecase Online.
This is in context of a website aiming to be AA WCAG 2.0 conform.
I have non-focussable text alongside focussable textinputs inside of a single view.
I can TAB through the focussable textinputs, but I cant read out the textfields inbetween. When I press "arrow down" while having the focus on the textinput I get "empty field" from NVDA. Most shortcuts also unfortunately produce text in the textinputfield instead of executing the associated behavior in NVDA.
Is there any way have the keystrokes being recognized as commands instead of input for the textfield? Is there any keyboard shortcut telling NVDA to behave like this?
Under the hood, NVDA auto switches to Forms mode, so what you're getting is the correct behaviour. if that text is related to the field, then you should use aria-describedby="[id of text]", on the form element.
I wouldn't be looking at anything that changes the default behaviour of how it works, as this will undoubtedly cause issues, for end users.
Could you not put that text in a tooltip, that is only shown when a user tabs to an interactive icon, next to the input (using the aria-describedby attribute too)?
I would like to implement Custom Entry (Xamarin.forms) when the user focus the Entry, device will show Emoji keyboard.
Short answer
Unfortunately it is impossible without creating your own keyboard, due to Android and iOS platform limitations.
Long answer
Default behaviour on iOS is to show the emoji keyboard icon in the bottom of the keyboard. So it is only one tap away from the user:
Default behaviour on Android is seems to be slightly different and the emoji keyboard is hidden by default:
Luckily, it is very easy to place the emoji keyboard icon by setting the InputType to Android.Text.InputTypes.TextVariationShortMessage | Android.Text.InputTypes.ClassText:
If you are still looking to show the emoji keyboard by default, I am afraid you will have to implement your own keyboard view. Depend on your needs you could add few emojis as buttons and etc.
https://learn.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/text/entry#customizing-the-keyboard
Customizing the Keyboard
The keyboard that's presented when users interact with an Entry can be set programmatically via the Keyboard property, to one of the following properties from the Keyboard class:
Chat – used for texting and places where emoji are useful.
Default – the default keyboard.
Email – used when entering email addresses.
Numeric – used when entering numbers.
Plain – used when entering text, without any KeyboardFlags specified.
Telephone – used when entering telephone numbers.
Text – used when entering text.
Url – used for entering file paths & web addresses.
This can be accomplished in XAML as follows:
<Entry Keyboard="Chat" />
The equivalent C# code is:
var entry = new Entry { Keyboard = Keyboard.Chat };
Following is a dummy implementation of our web application
https://roleapplication.herokuapp.com/index.html
appArea element has role application as it contains highly complex widgets such as ms paint/editor/ms office.
Navigator contains standard web widgets such as dropdown and buttons
The HTML is something similar to as specified below.
<body>
<div class="appArea" role="application">
.......//Complex widgets
</div>
<div class="toolbar">
......//Buttons, dropdowns
</div>
</body>
Keyboard functionality of appArea is handled by its code and for toolbar we rely on keyboard handling with the screen reader as they work in web browser.
Issue - When user press escape in navigator area we blur the navigator so the focus by default goes to body.
Now as focus is in body then arrow keys moves the focus to toolbar and therefore user is never able to go into appArea. If focus is in appArea it works fine.
Expectation - When focus is on body then on pressing down arrow focus should inside the appArea and then appArea will get the key instead of screen reader.
Check the down arrow key functionality when page is loaded with and without screen reader.
Keyboard notes
Press f6 to go from widget 1 to widget 2 to navigator
You can use arrow/tab keys in widgets to navigate.
Move to navigator using f6 and press tab to go to any button and then press escape. Now focus is on body(check using
document.activeElement).
Without screen reader our widgets captures the key on body and process it even if they dont have focus.
However with screen reader, when body has focus and user press down arrow, screen reader consumes the key and move the focus to navigator instead of application area which has widgets and user is unable to go to appArea using arrow keys or other keys which screen reader consume.
Note -
If we give role application to complete application then default arrow key handling of navigator will stop working which is not desired
Removal of role application is not possible as appArea is quite complex with hundreds of widgets all having their keyboard handling.
There are three ways to interact with role="application".
Hit enter on the application element, exit out of edit mode (or forms mode) and use the application as if it is another web page. You can put other elements there and the screen reader will move through those elements in brows mode.
Hit enter on the application which pops the screen reader into edit mode where all keys are passed to the edit widget inside the application. and you handle everything within your application, probably on a keydown event.
Control the tabindex as the screen reader presses keys using a roving tabindex.
You currently have 1 and 3 which is really confusing. If you removed the application element, it would still work just fine. It sounds as if you want 2 though. 2 is highly discouraged unless you have a screen reader user constantly testing UX or building your app. Number 2 is mostly for games and is considered the "canvas" element for screen readers.
You do 2 by doing the following:
<div role="application">
<input type="button" autoFocus="true" value="Click me" />
<p aria-live="polite" id="spk"></p>
</div>
The spk element is to send messages to the screen reader which you need to do in this Window, Icon, Menu, Message (WIMM) interface. Remember that in this mode, you need to program everything and users get upset if expectations are not met.
You said you are making a word processor. This last option (number 2), is NOT meant to make a word processor. As a screen reader user, I have expectations and workflows for Word processors. You can't get that functionality with programming it manually in Javascript.
Instead, use the existing edit fields HTML provides for this reason, such as:
This text editor example
Please let me know if there is some reason why you would not want to use the above widget.
You could get away with using 3 along with normal widgets, but it is better to do what Google Drive does and allow users to enter edit mode when the page loads, or press a key, like escape, to enter the tabindex application area (which does not need to be in an application element, although it can be).
Edit: After reading your question again, it sounds as if you can't figure out how to enter the application element. You arrow to where the screen reader says "application" and hit enter. To get out, you either tab to the next tabindex element that is outside the application or press the special key command to exit out of the application. In NVDA, this key command is ctrl+nvda+space. On your application, the application element is the first element.
role='application' should be used on rare occasions. As you noted, it causes all keyboard events to skip the screen reader and go directly to your app. This causes the screen reader virtual cursor to not work. Typically, a screen reader will automatically go into "application" mode (often called "forms mode") for certain types of widgets, such as an input field. If you are using widget roles, you will get this "forms mode" for free.
When you say "arrow keys" are not working, are you talking about up/down arrows or left/right arrows? They have different behaviors for a screen reader.
Background: for Windows users on Chrome and IE, dropdowns that reload or change the page are no good for accessibility. As soon as a user presses the down arrow button, the page reloads. This means that the user can only access the very first menu option. Here is an example: http://html.cita.illinois.edu/script/onchange/onchange-example.php
This is covered in the WCAG rule:
“Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)”
EXCEPT the user can very easily open up the dropdown and explore all the options without triggering an onchange event. The user does this with a space bar press. This is a very commonly known keyboard trick that I've seen all tested users to already be aware of or be able to figure out quickly.
In my system, we are using a dropdown for pagination in long directories.
EG: "you are on page [1^] of 16" (with the [1^] being a browser default dropdown menu). The designers will not allow any kind of visual [go] button. This happens across thousands of pages, javascript fixes I've seen need to account for every dropdown, and this is impossible on our case.
Using space bar, the user can see all the options and make a selection from anywhere on the list using only the keyboard. So why are dropdown page menus that automatically reload onchange still considered inaccessible? And would they be considered accessible if we included screen-reader only text which said "press space bar to open this menu, making a selection will load your next page"
Well except that in Firefox, the keyboard command is actually F4, you are correct - this is not a WCAG 2 violation but rather a best practice
Here is a page where you can test this: http://dylanb.github.io/onchange_select.html