It says it's OK to have a a in button

[juliemoynat]

Hi,

The request for "Can I include a in button" has a wrong result as it says it's OK but it's not because the content model is:

Phrasing content, but there must be no interactive content descendant and no descendant with the tabindex attribute specified.

[CyberLight]

The href attribute is optional for the <a/> tag, the caninclude tool does not know if this attribute is specified or not, so the final decision is made by the user, not the tool. The tool provides information on tags and a preliminary and non-final result of the possibility of including a tag in a tag, and the user makes a final decision based on the information on the tags. The existing mechanism for determining whether a tag can be included in a tag is based on a simple heuristic.

[juliemoynat]

So, instead of saying it's OK, maybe the tool should say "I don't know, it depends"?

[CyberLight]

I'm sorry, but with the current implementation and making the result of tag matching, this approach is not possible. Perhaps, in the next versions it will be possible.

[juliemoynat]

This is a huge accessibility problem to have links in buttons and, yes, developers do that sometimes. It makes the functionality (a button or a link? I can't know) unusable for some disabled people.
So I think, it would be better to tell "no, you can't" and then "go read the doc to see that, in fact, in a particularly rare case, you can do it".

We all know people don't read documentation. So, this "yes, you can" is dangerous for web accessibility.

[CyberLight]

Yes you are right!

Links to understand the presence or absence of an attribute in a link

• https://css-tricks.com/a-complete-guide-to-links-and-buttons/
• https://www.scottohara.me/note/2019/07/17/placeholder-link.html

Short conclusion for the current situation.

Since the absence of an href for a link means that this is a placeholder for a link or a disabled link (which is activated only after authorization or any user action). You are right, such a link cannot be included in the button even without the href attribute, since it turns out to be semantically incorrect (because if we simply add an href, we will get a violation of the specification). Using a link inside a button will also fail with ping attributes and so on, since it is recommended to omit their use without href attribute. Links without href can be used in the menu to disable any item without using span (this is useful of course).

Applied to the current implementation of tag comparison.

But now imagine that the current tag comparison engine will need to know this additional information, and not only rely on the description of conditions in the Categories and the Content Model of tags. Additional functionality needs to be added with exceptions and information where you can read and understand. I'm sure there can be such a problem with other tags too, if the engine follows the documentation but not the logic. Again, the context in which the tag is used matters. Even without additional attribute information, poor results can be obtained from "caninclude" website.

Additional information

Need help from the community to collect a list of semantically incorrect inclusion one tag to another that are not so obvious from the documentation, so that the simple mechanism doesn't just compare by following the documentation, but has support in the form of exceptional rules. Perhaps any ideas how to implement this is clearer for the end user

[CyberLight]

Previously, there was ticket #25 for this problem, but at that time the engine did not distinguish between conditional parameters (if ... then) in the category section of the tag. After solving the problem, the parsing of the documentation was changed to support conditional parameters, and I thought it would be understandable that way. But I missed important semantic points that are not in the documentation. In this case, the end user will need proof in the form of links to authoritative articles. And then let them decide how to use this information.
This functionality will definitely make the service better and more useful.

@juliemoynat Thank you for paying attention to this, for me it is very valuable.

[juliemoynat]

Thank you for taking this important point into account.

I'm not sure there are other cases like this but if I find one, I will tell you.

About the mechanism to ask precision about the attributes on the tag, it could be a second question like "does the parent tag have this attribute? [dropdown list of the interesting attributes]". According to the answer, it could change the content in the page.

[SelenIT]

Interestingly, the similar nesting "input inside button" is considered forbidden, although the input element may or may not be interactive content depending on its type attribute (<input type="hidden"> is not interactive content and thus technically can be nested in <button>, even if such nesting doesn't make much sense). What is the difference between these cases from the parsing perspective?

(There is another issue with the input case that some important "not" words are missing in its categories description, perhaps because it is marked with the em tag in the spec, but these issues seem somewhat related to me since it's all about parsing the spec)

[juliemoynat]

In the new version of the website, the problem I reported is fixed. Thank you. I close the issue.