Adding Heading to node links, Unordered List Items

I always struggle with what text to use for this heading which may be why there isn't one at the moment, I used to call them "Action links" but even that is wrong, don't want to use the "n word" here, any other suggestions?

Hmmm...

Please do not use the "n" ... "ode" word.

It is tremendously difficult to come up with a heading for these links, as * anything * can find its way into this list of links. Are there any good words that might best describe the relationship, generally, between the links and the content with which they are associated?

As a thought experiment we can ponder the ARIA roles model "contentinfo" http://www.w3.org/TR/wai-aria/roles#contentinfo which, on first thought in the middle of the night, seems appropriate. Is there a way that we can create a meaningful heading from the semantics of this role?

updating title

Possibly a literal "Content Links"?

@Jeff

That was the best idea that I have been able to come up with so far, but it's still the middle of the night :)

We do run into the stupid nesting headings problem based on context of the content.

As a single node view h1 for title and h2 for local tasks headings and "content links" headings is good.

However, in a list as on the default front page we end up, usually, with h2 for title and h2 for content links. Is it possible to make the "content links" heading single node view aware and to adjust the heading level accordingly? I would guess not since there really, afaik, is no way for the tpl file to know anything about its context other than if this is currently the front page.

We really need to come up with a better solution to this problem generally in D8.

Heading levels are way less of a problem in HTML5, I am going to make node titles H1 all the time, we use the other sectioning elements as they are more powerful, so we can make the links heading H2 with impunity, no problems there.

BTW guys I just downloaded the 7.x-2.x archive and this is not the HTML5 code its supposed to be, I think something has gone wrong with CVS, I'll wait until after the Git Migration tomorrow before doing anything about it. Grrrr....

I don't think we should use the actual role on links, since we can only use it once per page it needs to be on the page footer. Some themes are marking up links as <footer> which is probably OK, but really <footer> is for meta data such as author, date etc.

Regarding no invisible headings - not really sure about that, it will most likely depend on how screen reader software decides to support HTML5, for example if they can make use of the <nav> element or even role="navigation", so really it will depend on what our alternatives are.

I don't think we should use the ARIA role quite yet either. But, to clarify...

The contentinfo role is to be used once per document or application region. Therefore a frontpage w/ 10 nodes (documents) listed could have 11 contentinfo regions. 1 for the main page, one for each child document. Just keep reading the part of the spec after what Mike had quoted.

Don't agree Everett. Nodes are not application, they are article which is a subclass role of document. The spec says once per document, nodes are part of the document. Additionally it does not make sense to overwhelm AT with roles, a chief complaint of my earlier use of ARIA Roles in my themes, too many roles does not help according to user feedback, its better to have fewer more well targeted roles. Would having contentinfo on every nodes links really help? I don't think so.

Note: Because document and application elements can be nested in the DOM, they may have multiple contentinfo elements as DOM descendants, assuming each of those is associated with different document nodes, either by a DOM nesting (e.g., document within document) or by use of the aria-owns attribute.

I don't see how a list of nodes (as in Drupal nodes) passes as document within document, i.e. a Drupal node is not going to carry role="document", and in fact if we dig deeper into the spec we find...

Authors SHOULD set the role of document on the element that encompasses the entire document. If the document role applies to the entire web page, authors SHOULD set the role of document on the root node for content, such as the body element in HTML or svg element in SVG.

role="document" is going to be set on the root element, in HTML5 that is going to be <html>, so once per "document" really means what it says - once per page.

FYI Everett I have read the spec, many times, and keep up with changes, please do not assume I have not done this or that simply because I disagree with you.

Wow...

I assume that everyone either hasn't read the spec or, like myself, has forgotten what they have read. I offered an interpretation.

Clearly it's your theme, so you can make your own decisions, I'm just offering a perspective.

Sorry Everett, I didn't mean to be rude or obtuse, my apologies if I was in any way, I really do value and appreciate you taking the time to offer your opinion and views. Sorry, I got a bit miffed at being pointed to the spec, I do read them, a lot (however boring they are) and try to interpret them best I can- now I'm not saying that I am right, but from what I read thats the way I interpret it, and I think from experience we should limit roles in the page and not splash them about perhaps like RDFa is, I want to add value to the document, but I am cautious about adding too many roles or those that might have only partial relevance. If we were to use contentinfo in nodes there is no way I would add it to links, it would be added to submitted information.

Hmmm, menu is a very interesting approach and one I am more favorable towards, I'm not so familiar with this element and will look into it, from what I can tell it can take two attributes - type and label, label is meant to generate a visible heading. I'm going to read more about this, I think it most certainly looks like very strong candidate.

How many lists of links does a given drupal site tend to have and how do we best manage navigation between them?

This is a very difficult question and one I have thought about a lot over the past few months, especially with all the new elements we have at our disposal in HTML5. Too bigger question for here but one we will need to answer in due course.

This may be a bit short-sighted considering the lengthy discussion but how about using "Related Links" as the title in this case. Generic yet informative enough?