Accessibility ARIA issues with react-select - autocomplete

We are using react-select component in one of our projects and trying to resolve accessibility issues. Right now, there is no way to provide the required aria attributes to the input element which has the aria-autocomplete="list" attribute.
https://www.digitala11y.com/aria-autocomplete-properties/
Above is the reference link to what we are trying to achieve. Below is the short story from the above link.
If an element has aria-autocomplete set to list or both, authors MUST ensure both of the following conditions are met:
The element has a value specified for aria-controls that refers to the element that contains the collection of suggested values.
Either the element or a containing element with role combobox has a value for aria-haspopup that matches the role of the element that contains the collection of suggested values.
I opened a PR to add the ability to add ARIA properties to the input element. https://github.com/JedWatson/react-select/pull/4132
But I wanted to check if I'm missing something if anyone has already worked on this. Please let me know if you need any other details.

Related

Trying to understand a CSS chain

can anybody explain the following code snippet (used in CSS):
[type="checkbox"]:checked
I've tried to find this on various sites, I understand the pseudo class on the end but the square brackets have really got me stumped.
Thanks for reading.
this [type="checkbox"] is an attribute selector
[attr=value]
Represents an element with an attribute name of attr and whose value is exactly "value".
:checked is:
a pseudo class selector represents any radio (<input type="radio">),
checkbox (<input type="checkbox">) or option (<option> in a <select>)
element that is checked or toggled to an on state. The user can change
this state by clicking on the element, or selecting a different value,
in which case the :checked pseudo-class no longer applies to this
element, but will to the relevant one.
Which means you have a checkbox element checked
[type="checkbox"] is an attribute selector.
This specific selector will match any element that has the attribute type and that attribute's value is checkbox. Most would identify this as a selector for and input but is not specific enough to be limited to that element type. Other elements that accept the type attribute are <button> <command>, <embed>, <object>, <script>, <source>, <style> and <menu>.
You'll often see input pre-pended to a selector like the one above, i.e. input[type="checkbox"], when targeting specific types of input.
The square brackets target an attribute such as type for an input elemet.
In your case you're selecting a checked checkbox.

Kentico 9 macro for form field visibility

I have a custom page type, and the editor will have the option to enter the following
Image (from media library)
Video (from media library)
YouTube video ID
The field names are as follows
SlideImage
SlideVideo
YouTubeVideoID
So, if an editor ads a SlideImage, SlideVideo and YouTubeVideoID should not be usable. Same for SlideVideo and YouTubeVideoID.
Within the Visibility Condition fields, i'm going to assume a macro is needed for this. My logic is:
This field visible if Field A or B have data.
A possible approach can be to add an additional field, which determines the field that should be used.
Create a text field (let's say, SlideType) and use a radio button form control with your options:
image;Image
video;Video
youtube;YouTube
Tick the "Has depending fields" checkbox for this field, and tick the "Depends on another field" checkbox for the SlideImage, SlideVideo and YouTubeVideoID fields.
Your visibility conditions would then be simplified, instead of checking the values of multiple fields.
For example, the visibility condition for the SlideVideo field would be:
SlideType == "video"
This has a few benefits:
Easy to add new fields and configure the visibility conditions
Easy to check what needs to be rendered in the front-end - in your repeaters and other webparts, you can simply have conditional statements on the SlideType field to determine which field to use
Intuitive for the end user - the interface makes it clear which field is being used
Add this to Visibility condition in Page type field edit:
Fields.SlideImage.Value == String.Empty
Do not forget to set proper Has depending fields and Depends on another field properties depending on your needs. You can learn more about these properties here.
Let's say the column name on which this value of your depending field is "FirstName", so you can write in the dependent field -> Visibility Condition as
FirstName.value != ""
or
FirstName.value
You can twist the conditions for as many conditions as possible and can club more than one condition too.
I am also sharing links with you having a lot of examples from Kentico support
Dependency fields in Kentico
Using dependency fields in forms
Cheers,
Chetan

enterprise architect api: Add element to a collection

I have few short questions regarding Enterprise architect.
My question is regarding the automation interface. When following the instructions provided on this page: http://www.sparxsystems.com/uml_tool_guide/sdk_for_enterprise_architect/colle... in order to add a new element to the collection ( and the .eap file) it does not add the element. I can get data from the elements, modify and even delete them, but adding a new element does not work?
Instructions provided:
Call AddNew to add a new item.
Modify the item as required.
Call Update on the item to save it to the database.
Call Refresh on the collection to include it in the current set.
my java example:
elements is a collection of all the elements in the model...
org.sparx.Element elementEa = elements.AddNew("Requirement", "non-functional");
elementEa.Update();
elements.Refresh();
With the api is it possible to change the id or guid of an element since there are no methods specified in org.sparx for that?
One last thing... Is it possible to create a custom element in EA, for example a requirement which will not have the standard properties like difficulty, priority etc.. , but will have others? (normal properties, not tagged values)
The arguments to AddNew() are Name and Type, so to create a Requirement element you should specify "SomeRequirementName" and "Requirement".
You can't change the ID or GUID through the API, and your models would crash and burn if you did (connectors would be left dangling, elements would vanish from diagrams, etc, etc).
With an MDG Technology you can create very detailed stereotyped elements if you like, with their own visual representations (shape scripts) etc, but if you're after creating an element type with its own properties dialog the answer is no; there is no hook for a custom dialog in the API.
Collection<Package> packageCollection = myPackage.GetPackages();
Package consolidatedCfsSpecPackage = packageCollection.AddNew("somePackageName", "");
if (!consolidatedCfsSpecPackage.Update()) {
System.err.println("Not Updated: somePackageName");
}
packageCollection.Refresh();
This works for me. I suggest you to check return value of elementEa.Update() method you called. If it returns false, you can get the reason by calling elementEa.GetLastError().

Find CURRENTLY selected <option> with XPath

What's the correct XPath syntax to check if an option element is currently selected, or just to get the selected option element from a select element, on an open page with which the user, and JavaScript, may have interacted? Is this even possible with XPath, or does it lack the ability to look at DOM properties?
I can't find any documentation on this, and have (speculatively) tried:
//option[#selected=true]
//option[#selected="selected"]
//option[#selected]
but none of these work; they simply don't match any elements.
(In case it matters, I've tried this both using the $x function in the Chrome developer console, and using the find_elements_by_xpath method in Selenium for Python.)
Short answer: it's not possible.
Longer answer: XPath can look at HTML attributes, but it can't look at DOM properties. Selecting an <option> element in a <select> changes the selected property of the <option> to true, and also changes the value property of its parent <select> element, but it doesn't affect the attributes of either, so it is invisible to XPath.
To find <option> elements that have the selected attribute set, which is often how a page author might determine which option is initially selected, you can use //option[#selected]. But this does not find the currently selected <option>; changes that the user makes to the selection are invisible to XPath. There's no guarantee it will even find the initially selected option, since it's possible that the page author didn't put the selected attribute on any elements and either let the browser select the first option by default or had some JavaScript select the initial option via the selected property.
The multiple other answers here claiming that a selector like //option[#selected] can detect selection changes made by the user after the page loads are simply completely wrong.
Of course, if you're able to use CSS selectors instead of XPath selectors, then option:checked will do the job.
The problem could be the " (double quotes).
//select/option[#selected='selected'] - Will match the selected option, i am using this successfully.
//select/option[#selected='selected' and #value='specific value'] - Will only match the selected option if it has a 'specific value', i'm also using this.
If you are still having trouble, it could be an entirely different problem, perhaps there is no option node. I hope this helps.
I think we can use a knowledge from #Mark's answer and account that. Let's just find a node which HAS desired attribute:
tree.xpath('//select/option[#selected]/text()')[0].strip()
I tried "//option[#selected=''] and it has worked for me.
it is able to highlight the selected option within Page objects model.
I would try //option[#selected='true']
i.e. driver.findElements(By.xpath("//option[#selected='true']")).getText();

Is it allowed to use <label> tag without labeled control?

I need to show in a page a list of, let's say, person's properties that should be rendered more or less as follow:
name: Name
date: 1/1/2000
other: Other
Reading the doc they say:
The LABEL element may be used to attach information to controls.
So, is it the right tag to encompass the names of the properties like name, date...
even if there's not an <input> to associate with?
Nope, as per Quentin’s answer.
However, in HTML5, <dl> can be used for generic associations where <label> isn’t appropriate.
No.
It says that it can associate information with controls.
It does not say that it can associate information with anything else.
See also the newer (but draft) specification:
Some elements, not all of them form-associated, are categorized as
labelable elements. These are elements that can be associated with a
label element.
button input (if the type attribute is not in the hidden state) keygen
meter output progress select textarea
No, it is not correct to use the label element like that.
The important thing here is the meaning of may.
The LABEL element may be used to attach information to controls.
RFC 2119 (which the HTML4 spec follows) defines may:
May: This word, or the adjective "OPTIONAL", mean that an item is truly optional
So here, may does not mean the label element can be used for other purposes; it just means that it is not required to use a label element with controls.
As far as alternatives go, it depends what you want to achieve. If you are just trying to follow the spec closely, then I suggest using p and a strong element for each pair. If you want the data to be more meaningful to computers, you could consider using one of the Microformat specifications.
I partially agree with the answers so far but want to add that if you want to use labels for some reason, then I would display the property values in read-only controls, and then your labels will be valid.
I've done this using appropriate styling to differentiate the read-only controls from the functioning controls to avoid confusing your users. This was on a sequence of pages which built up the information gathered from the user in a wizard.
I have this link to W3C - the "Editor's Draft" as opposed to the link above which is the "Working Draft", which states that you can associate it with any element - as long as it's 'labelable' - even though this is a subsection of the Form section. It states earlier that a labelable element does not have to be within a form.
http://dev.w3.org/html5/spec/single-page.html#the-label-element