The W3C Nu Html Checker flags role errors on the ARIA 1.1 Accordion design pattern.

[LaurenceRLewis]

Nu Html Checker https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.w3.org%2FTR%2Fwai-aria-practices%2Fexamples%2Faccordion%2Faccordion.html

Tested: Accordion Example https://www.w3.org/TR/wai-aria-practices/examples/accordion/accordion.html

Results

Error: Bad value heading for attribute role on element dt. dt role="heading" aria-level="3" Error: Bad value region for attribute role on element dd. dd id="sect1" role="region" aria-labelledby="accordion1id" class="Accordion-panel"

[stevefaulkner]

will take a look, initial reaction, why would they use a dl to mark up an accordion...

[LaurenceRLewis]

Thanks Steve. Unfortunately I can’t answer why the DL option is used. I will ask.

[LJWatson]

This is a conformance error I think. According to ARIA in HTML, the heading role is not permitted on the <dt> element.

[mcking65]

This semantic structure was proposed by @accdc. I agree with the idea that the dt/dt pairing is a reasonable for an accordion. dl provides a semantic relationship between each dt/dd pair, that matches nicely with the accordion structure. It is very similar to using a ul for a tree.

I think we should consider allowing heading on dt.

[stevefaulkner]

I agree with the idea that the dt/dt pairing is a reasonable for an accordion. dl provides a semantic relationship between each dt/dd pair, that matches nicely with the accordion structure.

The semantic relationship is overridden by the roles added to the HTML elements.

Suggest that using div's work work just as well and comes with no styling baggage that dl/dt/dd have.

[LaurenceRLewis]

I understand that the DL structure matches the implied structure of an 'Accordion'. I agree with Steve this is lost when the roles overwrite the semantics. What is the main reason a dynamic list structure is suggested if the semantics are no longer announced?

My observations using JAWS 2018.1803.24 and IE11:

When arrowing down the page the DT with role heading and level JAWS announces: 'Personal information, use Jaws key Alt M to move to controlled element, button expanded'.

If I tab to the accordion DT Jaws announces: 'Personal information heading level 3 button ...' The heading role is listed in the Headings dialog.

An actual DL structure is announced as 'Definition list with x number of items'.

No idea if this helps :-)

[mcking65]

Yes, divs work ... they always work :).

I think the idea here is just like the idea of using unordered lists to make menus and trees. In both cases, the semantics of list are overridden. But, there could be other reasons for building a document in that way. It could be that you are reusing the same content in multiple ways, perhaps in a responsive design where the structure of a definition list is helpful for styling. Or, maybe there are some instances where the same content is fed to a system that displays it using a web component that extends definition list.

In general, most of the APG patterns have an underlying document structure that reflects relationships. For example, the tablist is a list, some of the grids are built from table, etc. In all cases, divs are just as good once you throw the ARIA on top. But, strip away the ARIA for any reason, and the structure may be helpful in some circumstances.

[LaurenceRLewis]

Thanks @mcking65 that makes a lot of sense.

[stevefaulkner]

@mcking65 I don't see substantive reasons provided to allow the override of current dl/dt/dd semantics of HTML elements other than those overrides already allowed in ARIA in HTML. For example, there is no history of the elements being used to represent accordions (no cow path) in deployed code. While there is for grids and interactive lists.

[mcking65]

@stevefaulkner, I thought the reasons for using dl to structure accordion that I provided were substantive.

I don't see any allowed roles for dt and dd in ARIA in HTML.

However, I see the following allowed for li: menuitem, menuitemcheckbox, menuitemradio, option, none, presentation, radio, separator, tab, or treeitem

I don't have a particularly strong opinion about use of dl in an accordion. However, I do not see the consistency in allowing ul to be used to structure menus, tabs, and radio groups but not allowing dl to be used to structure accordions, especially since the alternative is no structure at all.

What are the criteria for allowing a role to be used? Is the general approach to be as restrictive as possible or to allow anything that does not have clear downside?

@accdc, @jnurthen, do you agree with @stevefaulkner that there is no substantive reason to build accordion from dl and that we should change the example code in the APG?

[LaurenceRLewis]

Personally I think @mcking65 has a strong argument for allowing the role on the dynamic list structure. This may also standardise the layout for accordions, as the unordered list does for menu navigation. The purpose of these rules is to have uniformity in code structures, or at least I thought it was at least a part of the reasoning. If it was a democracy I'd have no hesitation voting for this change :-)

[stevefaulkner]

I thought the reasons for using dl to structure accordion that I provided were substantive.

Taking a native element structure and overriding its native semantics without obvious user benefit is not a substantive reason. The author conformance requirements of ARIA in HTML seek to encourage developers to make use of native HTML semantics over ARIA. The use of native elements in design pattern in question is, I suggest, unnecessary and overcomplicated: current design pattern:

<dl role="presentation">
<dt role="heading" aria-level="2"> <button aria-expanded="true" aria-controls="sect1" id="accordion1id" type="button">Personal Information</button>
</dt>
 <dd id="sect1" role="region" aria-labelledby="accordion1id">
...
</dd>
...
</dl>

Alternative simplified design making use of native semantics over ARIA:

<section>
<h2> <button aria-expanded="true" aria-controls="sect1" id="accordion1id" type="button">Personal Information</button>
</h2>
 <section aria-labelledby="accordion1id">
...
</section>
...
</section>

What substantive reason is there to promote the current design pattern which involves a change in author conformance requirements over the alternative simpler design which represents the same role semantics without the need to add ARIA?

I don't see any allowed roles for dt and dd in ARIA in HTML.

However, I see the following allowed for li: menuitem, menuitemcheckbox, menuitemradio, option, none, presentation, radio, separator, tab, or treeitem

Correct. This is because practical use cases for li have been demonstrated in the wild.

I do not see the consistency in allowing ul to be used to structure menus, tabs, and radio groups but not allowing dl to be used to structure accordions, especially since the alternative is no structure at all.

As demonstrated above, one obvious alternative is a structured pattern that represents natively the semantics applied using ARIA.

What are the criteria for allowing a role to be used? Is the general approach to be as restrictive as possible or to allow anything that does not have clear downside?

The general approach is to encourage authors to only override native semantics when necessary. This is sentiment is embodied in the following:

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so. Under what circumstances may this not be possible?

• If the feature is available in HTML but it is not implemented or it is implemented, but accessibility support is not.
• If the visual design constraints rule out the use of a particular native element, because the element cannot be styled as required.
• If the feature is not currently available in HTML.

[yatil]

Another alternative is using (a list of) <details> elements which degrade gracefully when JS is not available and can be easily scripted to work together as an accordion:

https://codepen.io/yatil/pen/PNVvLw

[accdc]

"I don't see substantive reasons provided to allow the override of current dl/dt/dd semantics of HTML elements other than those overrides already allowed in ARIA in HTML. For example, there is no history of the elements being used to represent accordions (no cow path) in deployed code. While there is for grids and interactive lists."

Actually I have seen this pattern many times on FAQ pages for clients, and it works fine. They use this because of the automatic styling afforded to them from this markup, and it is unreasonable to have to tell everybody to change it just because the ARIA-HTML spec says this is not allowed. Note the accessibility API mappings already support this and this consists of an accessible construct in all platforms no matter what the conformance checker actually states; you can see this by examining the role mappings in the accessibility tree.

This is supported by the ARIA 1.1 spec where it states the following within: 7.5 Conflicts with Host Language Semantics

"However, this provision does not give blanket permission for host languages to forbid the use of WAI-ARIA simply by documenting, feature by feature, that it may not be used." http://www.w3.org/TR/wai-aria-1.1/#host_general_conflict

[stevefaulkner]

@accdc

Actually I have seen this pattern many times on FAQ pages for clients, and it works fine.

If so then am happy to review examples in the wild.

"However, this provision does not give blanket permission for host languages to forbid the use of WAI-ARIA simply by documenting, feature by feature, that it may not be used." http://www.w3.org/TR/wai-aria-1.1/#host_general_conflict

Conformance requirements for use of attributes in HTML are defined in HTML not in other specifications. If you disagree then it should be raised with the HTML WG.

[stevefaulkner]

I googled Accordion FAQ JavaScript, I found the following from the first couple of pages of results:

• https://www.elated.com/articles/javascript-accordion/
• https://semantic-ui.com/modules/accordion.html
• https://codepen.io/ArielBeninca/pen/KdVJGO
• https://codepen.io/VEKIA/pen/ylswC
• https://www.jqueryscript.net/accordion/Simple-Smooth-FAQ-Accordion-with-jQuery-CSS-FAQ-Slider.html
• https://github.com/sizzlecentral/javascript-accordion-faq/blob/master/javascript-accordion.html
• https://www.elevated.com/need-accordion-layout-website-think-simple/

A search for ARIA FAQ accordions:

• https://github.com/nico3333fr/van11y-accessible-accordion-aria/
• https://www.scottohara.me/blog/2017/10/25/accordion-release.html
• http://web-accessibility.carnegiemuseums.org/code/accordions/
• https://codepen.io/chrisyaxley/pen/JsKhb

I have not found any scripted FAQs that use the dl/dt/dd pattern

[scottaohara]

A couple things here...

They use this because of the automatic styling afforded to them from this markup

1. Using markup because of its default styling, in the case of a dl it merely indents the content of the dd, seems like weak reasoning. In most situations, default styling is rarely a good reason to choose one markup element over another more appropriate alternative. Though for this particular scenario, one could argue that details and summary would be a much stronger argument for both semantics and default styling here...

2. That said, I don't have an issue with a dl being a base pattern for an accordion , but I don't understand why the semantics of the dl and its children weren't maintained. If the semantics of this markup pattern were really important to the accordion component (child elements being announced as list items within a definition list), then they should have stayed as is, and not been modified to headings and regions.

   From a document outline point of view, there should be purposeful reasoning to convey an accordion as a series of list items vs a series of headings and associated regions. However, if a standardization of headings and regions are the goal of the pattern, then it should be stressed that the appropriate HTML elements to create this structure should be used, and to not promote a markup pattern with very different semantics to be heavily modified with ARIA, instead.

   e.g. I would have expected:

   <h#>
     <button id="idref1" aria-expanded="t/f" aria-controls="sect1" aria-disabled="t/f">...</button>
   </h#>
   <section aria-labelledby="idref1" id="sect1">...</section>

[LaurenceRLewis]

I have found design patterns that use Unorderd Lists, Labels and Articles, Divs, Sections and Headings. Div and Ul LI being the most prevalent. No usage is overall more dominant than the others. Therefore, using an ‘in the wild’ case, as a basis for a design pattern is not applicable.

As a developer who cares about accessibility and a standards approach—what I would like to know—is how does the layout structure affect the end user. The end user this case is nominally a person who relies on a screen reader.

It is only in relatively recent times that Governments have legislated that websites must be accessible to all users. In Australia that was 2014. Because of this many developers will view official examples, such as, the ARIA Best Practice examples, as the model to work by. I know this is the case in the Government department in which I work, where currently there are many cases of the ARIA 1.1 Accordion design pattern in use. This is why it is important to find consensus on a design pattern going forward.

What are the pros and cons in using the different design patterns? What is required is a pattern for everyone to adhere to—as is the case with the Accordion’s cousin the Tab control, which dominantly uses an Unordered List. (UL LI) as the design pattern.

[jnurthen]

@stevefaulkner if the example were modified such that the roles were only added at runtime, then I could certainly see a benefit in allowing this pattern as it would give a much better experience for AT users if the scripting failed to load. The dl/dd/dt semantics would be very beneficial in this case.

I don't see any benefits in the code as currently written though - as I agree that it is no better than using a div. However I also do not see any adverse effects from it either.

There seems to be a fundamental philosophical difference. ARIA in HTML seems to require us to prove a benefit in allowing an element to have a role overridden, whereas the implementation philosophy of those writing ARIA practices is that we should allow roles to be overridden if it doesn't cause harm.

[stevefaulkner]

if the example were modified such that the roles were only added at runtime, then I could certainly see a benefit in allowing this pattern as it would give a much better experience for AT users if the scripting failed to load.

@jnurthen What I am failing to understand is the reasoning/preference to use the dl/dt/dd pattern for static display over the pattern of heading/region used for the scripted display. If it's a good pattern for dynamic content why would it not be good for static content? If a 'best practice' design pattern can be achieved using native elements with less ARIA why make it more complicated by recommending the use of ARIA to overwrite and duplicate the semantics of native HTML elements?

There seems to be a fundamental philosophical difference. ARIA in HTML seems to require us to prove a benefit in allowing an element to have a role overridden, whereas the implementation philosophy of those writing ARIA practices is that we should allow roles to be overridden if it doesn't cause harm.

During my time as editor of the HTML spec and my ongoing time as editor of the ARIA in HTML, HTML extension spec the fundamental philosophy has been the same for author requirements/constraints on all HTML features (including but not only ARIA attributes): If there is a substantive reasons/use cases to allow use of HTML features by modifying their currently defined semantics/conformance requirements then they will be considered. I suggest that encouraging people to change native semantics without good reason can be harmful as it undermines the value of the built in semantics and is not something we should be advocating.

[jnurthen]

@stevefaulkner One of the major uses of ARIA in the wild is retrofitting existing content. With long-lived code there is a strong reluctance to change the DOM structure as often there are unknown dependencies on that code (potentially with scripting running on top of the code of which the original author has no knowledge). The choice is often - add roles and other ARIA attributes to make the code better, acknowledging that it will probably never be perfect - or do nothing. The pragmatist in me says that we should patch things up to make things better. Having extra validation errors introduced when doing this becomes an impediment to improving products.

[accdc]

I agree, there are two seemingly opposed philosophies here, and I don't see a simple solution to address them.

The purpose of ARIA, and the reason why it was invented, was to provide a way to override the default browser mappings in the accessibility tree to restructure existing markup in ways that are not working accessibly, so that these structures with these new mappings would provide more reliable and intuitive experiences for people with disabilities using assistive technologies.

Specifically this was meant to address scenarios where dynamic behaviors are added to such markup yet there is no accounting for proper roles, states, and supporting properties to convey this interaction accessibly to assistive technology users. Mainstream developers do this every day.

In the case of the DL, I have seen many times where developers make DT elements clickable much in the same way that people have done with headings to expand content below them as part of accordion constructs. Telling them to stop doing that wasn't an option in all of these cases, and for this, ARIA specifically exists to provide a solution where no other solution is available to solve this problem. This is why it was invented, to provide a way to do this.

This has been described on the ARIA intro page for many years at https://www.w3.org/WAI/standards-guidelines/aria/

"WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. Currently certain functionality used in Web sites is not available to some users with disabilities, especially people who rely on screen readers and people who cannot use a mouse. WAI-ARIA addresses these accessibility challenges, for example, by defining new ways for functionality to be provided to assistive technology. With WAI-ARIA, developers can make advanced Web applications accessible and usable to people with disabilities."

It's important to note here, that this entire discussion about DL and DD elements and what role is or is not allowed in an accordion has nothing to do with accessibility, because if you actually test this construct with a screen reader, you will find nothing inaccessible or hypothetically wrong with the user interactions afforded to non-sighted screen reader users. This occurs because browsers map to these roles as they are applied, and when focus handling matches these correctly and if the correct states are applied, it results in an accessible widget, just as ARIA was always intended to do. What the construct is styled to look like literally has no impact and is totally irrelevant from the perspective of ARIA.

So the argument about this, as it appears to me, seems to revolve entirely around the shape of the box that people think ARIA should be stuffed into, and which parts should be cut away if they stick out of that box. And philosophically, this doesn't make any sense to me because it has nothing to do with what ARIA was originally invented to accomplish.

[stevefaulkner]

@accdc

I have seen many times where developers make DT elements clickable much in the same way that people have done with headings to expand content below them as part of accordion constructs.

Repeating such statements without providing actual examples is not helpful to your argument. Also you appear unwilling to explain why in a best practice design pattern it necessary or recommended to override, unnecessarily, the default semantics of HTML elements to recreate the default semantics of other HTML elements.

[LJWatson]

@accdc wrote:

The purpose of ARIA, and the reason why it was invented, was to provide a way to override the default browser mappings in the accessibility tree to restructure existing markup in ways that are not working accessibly, so that these structures with these new mappings would provide more reliable and intuitive experiences for people with disabilities using assistive technologies.>

I don't think ARIA was ever intended to replace perfectly good native semantics. It was intended to provide semantics where none existed in the host language.

Looking at the example design patterns in the APG, they seem to do one of two things:

• Apply native semantics to an HTML element that has no (real) native semantics of its own. The button role on a span element for example.
• Apply non-native semantics to an HTML element that has (actual( semantics of its own. The tablist role on the ul element for example.

I don't think there are any patterns that apply native semantics to an HTML element that has (actual) semantics of its own. The heading role on the dt element for example.

It strikes me that this is not a step we should be taking in the APG.

[jnurthen]

Oftentimes we want to use the same HTML on both large and small screens but override those semantics on one of them. Preventing this and requiring the use of semantically neutral elements doesn't seem like it is helpful.

[mcking65]

(Edited to fix poor choice of words pointed out by subsequent comment from @yatil.)

@mcking65 asks:

What are the criteria for allowing a role to be used?

@stevefaulkner answers:

The general approach is to encourage authors to only override native semantics when necessary. This is sentiment is embodied in the following:

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so. Under what circumstances may this not be possible?

• If the feature is available in HTML but it is not implemented or it is implemented, but accessibility support is not.
• If the visual design constraints rule out the use of a particular native element, because the element cannot be styled as required.
• If the feature is not currently available in HTML.

We all agree with that sentiment and that the above are good rules to promote in the practice of using ARIA. In the spirit of such sentiment, I will propose that the APG TF consider restructuring its accordion example in the way you suggest.

However, the question I have is whether this sentiment is an appropriate criterion for determining whether or not a given role should be allowed on a given HTML element? In other words, what should be the goal of restricting the ARIA attributes allowed on an HTML element with the ARIA in HTMLL specification so as to wield the heavy hammer of the W3C validator?

We have a sliding scale available. On the liberal end of the scale, the goal would be to allow anything that doesn't spark a fire that could burn down the house. On the conservative end, the goal would be to prohibit any use of ARIA that goes against the above sentiment. Should the ARIA in HTML specification lean liberal or conservative?

I argue that the downsides of a conservative specification are far greater than the downsides of a liberal specification and that it is counterproductive to attempt to force people into good practice via validation. It makes the perfect the enemy of the good.

Actually, I am not aware of any downsides to a more liberal ARIA in HTML specification. Sure, it means that the validator will not have the power to enforce ideal practice. But, my argument is that normative requirements are not the appropriate means for achieving that end.

Why? There are broader, more philosophic answers, but I'll take a practical accessibility approach to my answer.

Our goal is to make the world more accessible. That means, in part, make effective accessibility as simple, cheap, and consumable as possible. The downsides of an overly conservative set of normative requirements are that:

1. It adds UNNECESSARY cost.
2. It adds UNNECESSARY complexity.
3. It adds UNNECESSARY frustration.
4. It can potentially impede meaningful innovation.

For the first three points, let's consider a typical scenario like @jnurthen described. You've been hired to fix a site. You find an FAQ built from a dl with clickable dt elements that show and hide dd elements. The FAQ content and its packaging in the dl is coming from somekind of third-party CMS back-end. You have the constraints that 1) you can't change the CMS and 2) you are on contract to make the site compliant within a specific time frame.

Simple solution: you dynamically added the ARIA we have in the APG and it works. It's relatively cheap, fast, and effective. But, that was one month ago. ... You've since moved on and are working on fixing other site features. Now you find the most recent version of the validator is puking on your FAQ that was working. Frustration! To fix it now, you have to transform the HTML itself. That's more code, more complexity, worse for the customer in the long run, and worse for all users because the rendering is now slower.

There is no shortage of everyday scenarios like this. Get into large systems with lots of abstractions and changing the HTML is often a non-starter. Should the systems have been built differently, perhaps? But, they are what they are. Do we want those systems to generate the most accessible output possible? As we work on making that happen, do we want accessibility to be perceived as becoming progressively easier and more efficient? Or, do we not care if it is increasingly frustrating and difficult to understand?

This kind of frustration could actually push people in the safest direction possible ... always use divs and then add the accessibility with ARIA. That will never generate validation errors. Said another way, unnecessary frustration is almost guaranteed to be counterproductive if your goal is to promote best practice.

@stevefaulkner wrote:

During my time as editor of the HTML spec and my ongoing time as editor of the ARIA in HTML, HTML extension spec the fundamental philosophy has been the same for author requirements/constraints on all HTML features (including but not only ARIA attributes): If there is a substantive reasons/use cases to allow use of HTML features by modifying their currently defined semantics/conformance requirements then they will be considered. I suggest that encouraging people to change native semantics without good reason can be harmful as it undermines the value of the built-in semantics and is not something we should be advocating.

Unnecessary constraints, on the other hand, can devalue not only the built-in semantics but the value of W3C validation. To be practical, if they don't give up on accessibility, engineers will either shy away from semantic HTML altogether or avoid validation. I see this happen in real life. Engineers value code that works, is easy to read and understand, and tests well in the real world; the more divorced validation is from these values, the less valuable it is.

On the innovation point ... it is very difficult to anticipate the advantages and disadvantages of different ways of doing things. Consider the expanding list custom element described in this MDN tutorial. It makes a menu by extending ul. It seems to me that someone might want to extend dl to do the same kind of thing to make accordions. It may be the simplest HTML structure with the right set of relationships. And, it helps that definition lists are already frequently used for FAQs and similar content. Not being a developer of web components, I'm not sure this is a brilliant idea. But, my fundamental point is that if it is, it would be ridiculous for it to be abandon because of an HTML rule restricting how ARIA can be combined with HTML.

With respect to the current criteria for allowing ARIA roles on elements, I don't understand how the arguments for using ul for tablist and radiogroup are stronger than the argument for using dl for an accordion. The argument that it is easy to find radio groups built from ul is not meaningful. There are valid uses of HTML and ARIA that are hard to find and invalid uses that are easy to find. Popular usage doesn't necessarily correlate with utility, value, or validity.

Net:

1. Unnecessary restrictions on the use of ARIA are a barrier to creating the most accessible world possible.
2. As a core principle, the ARIA in HTML spec should not contain normative requirements that discourage accessibility.
3. As good stewards of accessibility, the Web Platform Working Group should proactively ensure that accessibility remediation of any HTML content is as simple as possible.

At the same time, the ARIA working group should not encourage unnecessarily overriding native semantics. So, in that spirit, we should consider changing the APG accordion example in a future release. But, the version that validated on December 14, should still validate today and should not be a barrier to APG release 2, which we are wrapping up right now.

[mcking65]

@LJWatson commented:

I don't think ARIA was ever intended to replace perfectly good native semantics. It was intended to provide semantics where none existed in the host language.

Completely agree. But, that is not the only intent. One intent from the beginning was for it to help support remediation. One of the first roles to do that ... presentation. <table role="presentation"> was all about remediation ... still is.

Looking at the example design patterns in the APG, they seem to do one of two things:

• Apply native semantics to an HTML element that has no (real) native semantics of its own. The button role on a span element for example.
• Apply non-native semantics to an HTML element that has (actual( semantics of its own. The tablist role on the ul element for example.

I don't think there are any patterns that apply native semantics to an HTML element that has (actual) semantics of its own. The heading role on the dt element for example.

We definitely work to avoid that. However, it isn't always practical. For example, a button may be turned into a radio to demonstrate custom radios, a link turned into a checkbox to demonstrate a custom checkbox, a textbox turned into a spinbutton to demonstrate a custom spinner, etc. I don't know if you consider radio, checkbox, and spin button to be native semantics, but I assume so because there are HTML elements with those semantics.

So, the third thing that happens in the APG is that we demonstrate how to create a custom version of a native semantic by overriding the semantics of an element that provides some properties that are important to the interoperability of the custom element.

[yatil]

(W3C hat off.)

@mcking65 wrote:

I argue that the downsides of a conservative validator are far greater than the downsides of a liberal validator and that it is counterproductive to attempt to force people into good practice with the validator. It makes the perfect the enemy of the good.

There is no such thing as a conservative validator or a liberal validator. There is a specification, in this case, HTML 5.2, which does not allow a role attribute on a <dt> element:

https://www.w3.org/TR/html52/grouping-content.html#the-dt-element

Allowed ARIA role attribute values: None.

The validator validates against the specification. If the validator does not yield the result you want, you need to change the specification.

Of course, you can build your own linter that adheres to your own rules. But that’s not validating against the HTML spec.

[accdc]

Hi Eric,

It was the end of the quarter last week, so I didn't have a chance to read through this until today.

I understand what you are saying about the HTML spec, and what it states. However there is a broader disconnect here that appears to have got lost in the weeds as far as this discussion goes.

The HTML spec does not solely control ARIA usage conformance. From this thread, and from what I've been told by others in the past, the assumption is that the ARIA-HTML spec solely dictates ARIA usage criteria within web technologies.

For many reasons this is not true. First, ARIA roles map within the accessibility tree regardless which element it is applied to, no matter what the HTML spec says. This is because ARIA is a separate technology and browsers handle this directly in accordance with the ARIA spec.

I understand about proper HTML conformance, and the importance of it, but it's very important for people to understand always that ARIA is not just a bunch of attributes that can be added to stuff, but that there ar real and specific changes that occur whenever these roles are applied, no matter on which elements.

No matter what the ARIA-HTML spec says should happen, browsers must continue to map roles correctly in accordance with the ARIA spec, because if they do not, all the reasons that ARIA exists will fall apart.

So, regarding the APG, yes, the example can be changed to not use DL/DT/DD elements, but doing so will not in any way change that this is still a valid usage of ARIA regardless.

It is for this reason specifically, that the ARIA spec states in section 7.5: "However, this provision does not give blanket permission for host languages to forbid the use of WAI-ARIA simply by documenting, feature by feature, that it may not be used.".

[yatil]

(Again, no W3C hat on.)

@accdc I understand that. But I don’t think any specification can give or get blanket permissions from other specifications. ARIA doesn’t care for any semantics of the host language. The host language does, and I think it it’s their good right to guide and prescribe it to authors. Otherwise, we could get rid of HTML and directly only use ARIA.

I agree that user agents should allow overwriting any semantics (which leads to so many accessibility problems in the wild because of lackluster implementations :-/), there is no way around that. However, I feel rather strongly that the relative simplicity and guidance of HTML help implementors. We can’t expect the HTML validator to also validate ARIA and then prefer ARIA over the HTML spec.

The reason that ARIA is allowed in HTML elements at all is that HTML5 allows the roles and attributes: https://www.w3.org/TR/html52/dom.html#aria-role-attribute HTML4 did not allow it, resulting in validation errors from an HTML4 view. Those documents were all right from an ARIA viewpoint.

The validator checks from the HTML viewpoint and therefore it makes sense to mark it as an error.

[LaurenceRLewis]

Reading the comments I see merit and reasoning from both sides and I have no hats on :-) If the issue is the way this is reported as an error, can it not be changed in the validator to a warning? Warning: ARIA is overwriting the HTML semantics for X.

[stevefaulkner]

@accdc Another specification cannot dictate the author conformance requirements of HTML. The rules for use of HTML are defined in the HTML specification. Whether you or anybody thinks this is appropriate, is another matter. Am closing this comment, feel free to re-open if new information arises.

[stevefaulkner]

@accdc re: repurposing of dl/dt/dd for ARIA practices

When a feature in the host language with identical role semantics and values is available, and the author has no compelling reason to avoid using the host language feature, authors SHOULD use the host language features rather than repurpose other elements with WAI-ARIA. https://www.w3.org/TR/wai-aria-1.1/#host_general_conflict