The W3C Nu Html Checker flags role errors on the ARIA 1.1 Accordion design pattern. #110
Comments
|
will take a look, initial reaction, why would they use a |
|
Thanks Steve. Unfortunately I can’t answer why the DL option is used. I will ask. |
|
This is a conformance error I think. According to ARIA in HTML, the |
|
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. |
The semantic relationship is overridden by the roles added to the HTML elements. Suggest that using |
|
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. 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 ...' An actual DL structure is announced as 'Definition list with x number of items'. No idea if this helps :-) |
|
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. |
|
Thanks @mcking65 that makes a lot of sense. |
|
@mcking65 I don't see substantive reasons provided to allow the override of current |
|
@stevefaulkner, I thought the reasons for using I don't see any allowed roles for However, I see the following allowed for I don't have a particularly strong opinion about use of 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 |
|
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 :-) |
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: Alternative simplified design making use of native semantics over ARIA: 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?
Correct. This is because practical use cases for
As demonstrated above, one obvious alternative is a structured pattern that represents natively the semantics applied using ARIA.
The general approach is to encourage authors to only override native semantics when necessary. This is sentiment is embodied in the following:
|
|
Another alternative is using (a list of) |
|
"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." |
If so then am happy to review examples in the wild.
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. |
|
I googled Accordion FAQ JavaScript, I found the following from the first couple of pages of results:
A search for ARIA FAQ accordions:
I have not found any scripted FAQs that use the dl/dt/dd pattern |
|
A couple things here...
|
|
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. |
|
@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. |
@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?
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. |
|
@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). |
|
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 "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. |
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. |
|
@accdc wrote:
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:
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. |
|
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. |
|
(Edited to fix poor choice of words pointed out by subsequent comment from @yatil.) @mcking65 asks:
@stevefaulkner answers:
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:
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 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:
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 With respect to the current criteria for allowing ARIA roles on elements, I don't understand how the arguments for using Net:
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. |
|
@LJWatson commented:
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.
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. |
|
(W3C hat off.) @mcking65 wrote:
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 https://www.w3.org/TR/html52/grouping-content.html#the-dt-element
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. |
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.". |
|
(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. |
|
Reading the comments I see merit and reasoning from both sides and I have no hats on :-) |
|
@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. |
|
@accdc re: repurposing of dl/dt/dd for ARIA practices
|
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"
The text was updated successfully, but these errors were encountered: