Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Semantic use of <section> not always standards compliant, consider using <div> #67

Closed
robw-ddsn opened this issue Sep 4, 2017 · 3 comments

Comments

@robw-ddsn
Copy link

robw-ddsn commented Sep 4, 2017

Firstly... keditor is a great little product. Well done! We hope to contribute however we can.

Accessibility and the associated semantic HTML markup are important to us with our CMS platform. Keditor uses section tags to identify containers and content components. Although this is sometimes semantically accurate, it often isn't.

Consider the W3C definition of the section tag:
https://www.w3.org/TR/html5/sections.html#the-section-element

The important note is:

The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content. The theme of each section should be identified, typically by including a heading (h1-h6 element) as a child of the section element.

This is also good reading:
https://stackoverflow.com/questions/6939864/what-is-the-difference-between-section-and-div

Although this use of section tags doesn't fail accessibility tests per se, it raises warnings, and it is invalid in many scenarios. The problem is that section adds meaning to the content snippet, and sometimes it should not. A better approach would be to use a div, which does not add meaning to the contained content.

The approach is valid sometimes, e.g. if the content snippet is a HTML block with headings and text. However consider where a snippet is used purely for layout purposes, or only to embed an image or other element that's a natural part of the content surrounding it and not part of the content structure that would appear in a table of contents. In this case, keditor adds meaning that is misleading to accessible browsers.

We attempted to do a quick-and-dirty hack on keditor.js to replace anywhere that references the section tag with div class="keditor-section" instead, and it almost worked... But not quite. There seems to be some reliance on a specific DOM structure in keditor that this approach disturbs.

Would you consider altering keditor's approach to use div tags instead of section tags (and leaving the use of the section tag up to the content designer), or perhaps providing a configuration option that allows the editor to be used both ways?

@bradmac
Copy link
Contributor

bradmac commented Sep 4, 2017

👍

Note that any change needs to preserve content editing compatibility with content developed using the current section format

@robw-ddsn
Copy link
Author

That's a good point, for backward compatibility if the editor is already in use of course. And it's not quite as easy as just swapping out section tags for div class="keditor-section", because there might be section tags within the content itself.

@ducdhm ducdhm self-assigned this Oct 24, 2017
@ducdhm ducdhm added this to the 1.1.5 milestone Oct 24, 2017
@ducdhm ducdhm modified the milestones: 1.1.5, 1.1.6 Nov 16, 2017
@ducdhm ducdhm removed this from the 1.1.6 milestone May 3, 2018
@ducdhm
Copy link
Contributor

ducdhm commented Jul 21, 2019

With new update, section tag will be replaced by div tag. All existing section tags are still working!

@ducdhm ducdhm closed this as completed Jul 21, 2019
@ducdhm ducdhm added this to the 2.0.0 milestone Jul 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants