Required properties and default values

[WilcoFiers]

Auto-WCAG is currently working on a rule regarding required aria attributes. The question that came up was if required attributes with default values should actually be treated as required.

The ARIA 1.1 spec isn't particularly clear about this, firstly saying the following in 5.2.2:

Content authors MUST NOT use the value undefined for required states and properties, unless undefined is an explicitly-supported value of that state or property.
https://www.w3.org/TR/wai-aria/#requiredState

But than about default values it says the following in 6.3:

When a value is indicated as the default, the user agent MUST follow the behavior prescribed by this value when the state or property is empty or unspecified.
https://www.w3.org/TR/wai-aria/#state_prop_values

My guess would be that required attributes with default values would not need to be set by the content author. From some quick testing, that certainly seems how browsers behave today. Can someone provide some clarity about this?

[stes-acc]

Regarding Defaults in general:

It is always a good thing to state the obvious. Not with humans but with software.

Danger is if you don’t explicitly declare defaults, there may be ambiguities in Platform API mappings across the different user agents. Reality has shown this for certain combinations.

A list of recommended candidates would be good where to believe in correct implicit default mapping and where not.

[WilcoFiers]

As far as accessibility support goes, I totally agree with you, there certainly are cases where you can't rely on the default to be consistent between platforms. It's more a question of where does the ARIA spec stand on this.

ARIA 1.1 clearly says that content authors MUST NOT leave the value of required properties undefined, while also saying that user agents MUST use the default when a property/state isn't set. Those seem like to contradictory statements.

Does "use the value undefined" mean having an empty attribute, rather than not having the attribute at all? So <div role="combobox" aria-expanded> means aria-expanded is undefined, while <div role="combobox"> means aria-expanded is false (the default)? That'd be my reading of it, but that's just a guess.

[WilcoFiers]

@jnurthen Any input?

[jnurthen]

https://github.com/w3c/aria/wiki/Required-Properties-with-Default-Values is the list of states and properties with this issue

[annethyme]

Adding even more to the confusion, user agent support for implicit values for roles is only a SHOULD in the the Core Accessibility API Mappings 1.1:

"Where the author has not provided values for required attributes, user agents SHOULD process as if the default value was provided,"

[carmacleod]

I added a "Notes" column to the Required Properties with Default Values Table.

Typical notes in this column are:

• "Required. Default in Core AAM Default Values Table only."
  This means that I believe the State/Property is actually required (i.e. "Content authors MUST provide a non-empty value for required states and properties."), and the default value is intended to be used by user agents that are trying to do something reasonable if the author doesn't provide a value. Therefore the default value only needs to be listed in the Core AAM Default Values Table, and it can be removed from the ARIA spec.
• "Supported. Default in ARIA and Core AAM Default Values Table."
  This means that I believe the State/Property should be supported but not required. The default value is intended to help authors decide whether they need to provide a value (i.e. if they need the value to be different from the default). So the default value needs to be listed in the ARIA spec for the role as well as in the Core AAM Default Values Table, so that both authors and user agents are using the same value.

Additional notes and questions:

• I'm not sure about the 4 aria-valuenow attributes - should they be Supported instead of Required?
• option and treeitem no longer have default values, and they're not in the Default Values Table, so no action required
• default values for separator (focusable) aren't in the Default Values Table, so they need to be added
• need to ensure that role entries in the Core AAM Role Mapping Table refer to attributes that need default values, e.g. checkbox has: See also: aria-checked in the State and Property Mapping Table
• need to change the wording in the Author Errors section in Core AAM and the caption for the Core AAM Default Values Table to allow for Supported attributes that need a default value, not just Required.

@annethyme

Adding even more to the confusion, user agent support for implicit values for roles is only a SHOULD in the the Core Accessibility API Mappings

I will try to find out whether this can change to MUST. Same for the Author Errors section in Core AAM:

If a required WAI-ARIA attribute for a given role is missing, user agents SHOULD process the attribute as if the values given in the following table were provided.

[jnurthen]

We will put this on the agenda for the meeting on Sept 6.

[schne324]

The default value (or fallback) of aria-valuenow for the scrollbar role seems off. I would argue that defaulting to the value of aria-valuemin makes more sense due to the common convention of scrollable elements having an initial state of being scrolled to the top. I'm imagining a (poor) implementation which only gives the aria-valuenow attribute a value once a "scroll" event has taken place (and initially omits it).

- Harris

[carmacleod]

Meta comment from wiki (moved here to make discussion easier):

@joanmarie questions if we want to maintain the fallback/error-correction information in the Core AAM. The Core AAM (Accessibility API Mappings) tells implementors how to expose roles, states, and properties for each accessibility API. If an author makes the error of failing to provide a value for a required property, the corrective measures taken by the user agent (e.g. exposing "2" as the level of a heading without an aria-level) are independent of the Accessibility API. Things that have nothing to do with Accessibility API mappings do not belong, in her opinion, in an Accessibility API Mappings spec. An alternative solution would be to add a new section to the ARIA spec stating what user agents should do to correct for missing values of required properties.

[carmacleod]

@joanmarie your alternative solution may be the way to go:

An alternative solution would be to add a new section to the ARIA spec stating what user agents should do to correct for missing values of required properties.

I looked (quickly) through open issues containing the words "supported" and "required", and I see that "required attributes with default values" are a problem for conformance checkers too. (i.e. if the default value was set by the UA, is a missing required value still an author error?)

I still need to go through those issues in more detail. There are some hidden gems in there, such as this table the aXe people created showing the current support for aria-expanded on combobox. :)

[carmacleod]

When the updates are complete, need to open an HTML issue/PR to update this table in the HTML spec.

[jnurthen]

I believe there are Issues/PRs for all of these now (mostly merged)
#862 #861 #860 #859 #858 #857 #856 #855 #854 #853 #826 #797 #780
Closing this one