There are several usernames that match the (short) name of the group so that the name of the group is not listed when I type it into the "Change Reviewers" field. Instead, I just see all of the matching usernames (unblocking and blocking versions) in the typeahead results box.
Use the "browse mode" dialog to see more results. This is, as far as I know, the only option when there are more results than can be displayed within an inline typeahead.
tldr; To open the browse dialog, simply click the magnifying glass icon at the end of the input field.
This is covered, albeit briefly, in Phabricator's Search Documentation
Related
I have "export", "refresh" and "add" buttons on different pages. The "export" button exports content of the current page. "Add" adds items depending on the page a user is on (users, servers etc.) and "refresh" refreshes the current page.
Is that allowed according to WCAG 3.2.4? Or do I need to rename things in "add user", "add server", "export users", "export server"...
Thanks,
Thorben
The fourth example on the Understanding Success Criterion 3.2.4: Consistent Identification article that's part of the W3's WCAG 2.1 spec seems analogous:
An e-commerce application uses a printer icon that allows the user to print receipts and invoices. In one part of the application, the printer icon is labeled "Print receipt" and is used to print receipts, while in another part it is labeled "Print invoice" and is used to print invoices. The labeling is consistent ("Print x"), but the labels are different to reflect the different functions of the icons. Therefore, this example does not fail the Success Criterion.
Rather than just labeling the icon "print" and letting users infer what it prints from the context of the page, they've labeled it differently in each specific context.
This would suggest that you should label your buttons "add user", "add server", etc.
Its not a WCAG failure, if same button label is not used for any other functionality (means 3 "add" buttons are there in page but has different functionality to add user, add admin, add project etc.)
Its best if we describe the purpose in text.
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 want to trigger a tag when a link with a certain css class is clicked. I create a trigger based on Clicks > Just Links, but when I go to select the variable, I just get "Page Hostname, Page Path, Page URL, Referrer, New Variable"... no "Click Class" as one would expect.
All the online help shows an outdated version of GTM that don't match the options I see. Even the GTM help docs are outdated.
How does one trigger by css class? (I tried using a custom variable, but didn't work either, and honestly the options didn't make much sense either).
Update: It works if I create a new custom variable "DOM Element has CSS selector" and then go to Trigger, select my custom variable, select "Equals" and enter the text of the link.
But this doesn't make much sense to me, all I want is trigger based on css class, not by the text contents of the tag.
Turns out GTM's "Click Element" built in variable (and many others) is off by default, that's why it was missing from the trigger dropdown. One has to go to Built In Variables > Configure > and tick the "Click Element" variable.
Why would they turn this off by default and offer no clues in the UI, I have no idea.
We are using Visual Studio online as our backlog/sprint planning system. Now VSO development team has introduced possibility to define epics, which is great.
But the problem is that I already have full backlog with features and backlog items. I can not find a way how to assign those features to newly created epics... (the same if I have created backlog item first and after that - if I create a feature, I can't find a way how to attach that aforementioned backlog item to the newly created feature)
I am stuck and can't find a way how to accomplish this. Is it at all possible? Can anyone shed some light?
Yes, follow the steps below to accomplish this:
From Epics:
Open the Epics item.
Click "Link to..." button under "Features" tab.
Select "Child" link type and enter the ID of the feature you'd like to assign to this Epic.
From Features
Set "Mapping" to "On" and you will see the Epics listed in the right
panel.
Drag and drop the feature to the Epic you'd like to assign.
Or you can also:
Open the feature item.
Click "Link to..." button under "All Links" tab.
Set "Link Type" to "Parent" and enter the ID of the Epic you'd like to assign.
The steps above can be also used when you want to assign backlog item to feature.
An easier way is to use the "Mapping" pane on the "Backlogs" tab:
Go to the "Feature" level
Activate the "Mapping" pane
Now simply drag & drop your features onto the epic you want:
The Epic work item form should have a FEATURES tab where you can associate existing or add new features (that are automatically associated to the Epic)
I have a list of options from which one can be selected. For all intents and purposes HTML's <select> element covers this. Since we need a different visual presentation, I'm looking at using WAI ARIA role="listbox". I'm unclear on how to use aria-activedescendant, aria-selected and aria-checked.
Questions regarding focus/active state:
If I use aria-activedescendant on the listbox to point to the [role="option"] that is currently active (has "virtual focus"), I would use [aria-selected]. How would best I tell the option element itself that it is active (has "virtual focus") to represent that visually? (:focus is on the listbox, after all)
an [role="option"] can have [aria-checked] and [aria-selected]. I guess I need [aria-selected] but don't see what I'd use [aria-checked] for.
Is there a trick to avoid having to put IDs on every option simply so it can be referenced by aria-activedescendant?
Questions regarding keyboard interaction:
"Checkbox - Space toggles checkboxes, if the list items are checkable" - how do I figure out if they are checkable or selectable?
Questions regarding validation:
If the listbox has [aria-required="true"] some sort of validation has to be performed. specifically if an option has been selected (or checked).
when do I trigger the validation? is on blur sufficient?
when invalid, what do I have to do besides setting [aria-invalid="true"] on the listbox?
aria-checked is indeed more something for a list of very closely related options with actual visible checkboxes that can be toggled on or off. This is most common in the Windows world. Explorer can be set to such a pseudo multi-select mode, or some apps use that to activate or deactivate a set of accounts. On the Mac, you can think of the list of accounts in Adium, which can be either checked (active) or not. A selection will always be there, and one or more of their checkboxes can be checked or not.
aria-selected is always the right one to indicate the selected state of an option. E. g. when traversing the list with the arrow keys, aria-selected="true" moves from item to item, while the others must then get aria-selected="false". As Patrick said, you can use this to also generate some nice looking CSS.
As for keyboard interaction: arrows up and down will select an item, and if the items are checkable, too, space will toggle the checked or unchecked state of the currently selected item.
In a true multi-select, like html:select #size>1, and multiselectable being true, the interaction would be:
Arrow keys select a single item.
Ctrl+Arrow keys would move focus from item to item, but not select the item yet.
Ctrl+Space would select the item.
Shift+up and down arrows would select contiguous items.
This is, again, standard Windows paradigm, can be observed in Explorer in Details view, for example.
As for validation: onBlur is sufficient, or you could dynamically do it via changes in selection/focused item, make sure at least one item is selected, or whatever validation you need.
aria-invalid="true" is sufficient for screen readers to know, but an error message and possibly a visual indication would be nice for everyone to know what's wrong.
How would best I tell the option element itself that it is active (has "virtual focus") to represent that visually?
Generally, you'd add aria-selected="true" and then craft some CSS that takes care of it using attribute selectors, e.g. div[role=option][aria-selected=true] { ... }, or add a css class dynamically?
[aria-checked] and [aria-selected]
This is more of a philosophical question I guess. aria-selected more closely matches what you'd have with a select...but then again (particularly for multi-select widgets) you can imagine the listbox actually being a series of checkboxes, and in that case you'd use aria-checked. there's no definitive right or wrong about either one (something you'll find a lot once you dive into more complex ARIA widgets).
Is there a trick to avoid having to put IDs on every option simply so it can be referenced by aria-activedescendant
Hmm...perhaps you could dynamically generate IDs for all options on page load via script? Or - but not tested - you could have something like a "roving" ID that moves around the options depending on which one is active (adding/removing the ID to the relevant option).