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

Making the Cassiopeia template more accessible #68

Open
zwiastunsw opened this issue Apr 14, 2020 · 11 comments
Open

Making the Cassiopeia template more accessible #68

zwiastunsw opened this issue Apr 14, 2020 · 11 comments

Comments

@zwiastunsw
Copy link
Contributor

zwiastunsw commented Apr 14, 2020

Intruduction

HTML 5 has provided new semantic tags that are used to organize the pages on website, such as: header, main, footer, aside, nav, section, form and a new role attribute (complementary, conteninfo, search, region, etc.).

Over the past six years, rules have been very precisely defined for identifying key areas (landmarks) of the page using these new tags and the role attribute.

The use of these elements is particularly important for users of assistive technologies. For example, screen readers provide navigation through landmarks. It can be expected that such a function will also be implemented in modern browsers or that special plugins for browsers will be created (the Landmarks plugin for Chrome already exists).

Unfortunately, the default Joomla 4 template - Cassiopeia - did not apply these rules. As a result, the default template does not provide essential functionality for digital accessibility. It is also not a good design pattern for template creators.

Rules

  1. the entire page should be divided into key areas (named landmarks), no content may be outside these areas,
  2. each area must have a specific role in the page structure given by a structural tag or the role attribute,
  3. only one area can have the main role,
  4. the main area must be the top level area (landmark),
  5. only one area can have the role of a banner (header tag; a page can have only one page header),
  6. the banner area (header tag ) must be the top level area (landmark),
  7. only one area can have the contentinfo role (footer tag; a page can have only one page footer),
  8. the contentinfo area must be the top level area (landmark),
  9. more than one area can have a nav role,
  10. the nav area can be part of another area (landmark),
  11. more than one area can have a complementary role,
  12. complementary areas must be top-level areas (landmarks)
  13. more than one area can have a search role,
  14. more than one area can have a role region,
  15. more than one key area of ​​the same type (performing the same role) must have a unique name.
  16. the key area (landmark) name can be given using aria-label or aria-labelldeby

A new structural element of the template is needed

Since there may be several areas on the page that serve as role="complementary" or role="region", a new structural element of the template is needed. It is a container in which modules can be placed and which can be given an accessible name.

It is best to define a new container using the section tag.

It should be a container in which to place modules and to which you can give an accessible name. The accessible name can be hidden or explicit. The administrator should be able to specify both an explicit and a hidden name.

The explicit name should be the area header (at the h2 level) with the identifier that should be pointed to by the aria-labelled attribute of the section tag.

The hidden name only for assistive technologies, should be the aria-label attribute added to the section tag.

References

See:

@zwiastunsw zwiastunsw changed the title Provide a pattern accessible page structure in the Cassiopeia template Making the Cassiopeia template more accessible Apr 14, 2020
@carcam
Copy link

carcam commented Apr 21, 2020

In the current output of the template I see this structure:

<body>
    <div class="grid-child container-header full-width "><header></header></div>
    <div class="grid-child container-top-a "><div class="top-a"></div></div>
    <div class="grid-child container-component">
        <div class="main-top"></div>
        <div class="system-message"></div>
        <nav class="navigation">BREADCRUMBS</nav>
        <div class="COMPONENT AREA"></div>
    </div>
    <div class="grid-child container-sidebar-right">SIDEBAR MODULES</div>
    <footer></footer>
</body>

After reading your comment and as per my understanding we should use this structure:

<body>
    <header></header>
    <aside>TOP-A</aside>
    <main>
    <nav class="navigation">BREADCRUMBS</nav>
        MAIN_TOP
        SYSTEM MESSAGES
        COMPONENT
    </main>
    <aside>SIDEBAR MODULES</aside>
    <footer></footer>
</body>

Right? Is it correct to place breadcrumbs (as a nav menu) inside the main content? Also there are 2 very likely positions for menus. One called menu, which is included in the top right area (Header) and the other is as a sidebar module.

@zwiastunsw
Copy link
Contributor Author

Generally.

  1. Use the section tag instead of the aside tag. You can use an aside tag on the sidebar (but it's not the rules )
  2. It is not enough to use a section tag to create a key area. A section must have an accessible name, given by the attribute aria-label or aria-labelledby.
  3. Breadcrumb cannot be part of main. Breadcrumb refers to the entire page, not just the main content.
  4. System messages cannot be part of the main. System messages refer to the entire page. They are best placed above the main part.
  5. "MAIN_TOP_" cannot be part of the main. Only component can be part of the main.
  6. The main navigation in the header must be separated. Currently, the main navigation landmark also contains a logo, a site description, a search engine.

The most difficult problem is creating sections. There may be several modules in a section. You could build a section from a module, in which other modules will be embedded.
But the section must have a accessible name. The administrator must be able to decide if the name is given only by aria-label in the section tag or by aria-labelledby and a visible or hidden heading. That's why I wrote that it is necessary to develop a new template element type, similar to <jdoc include type="module" ...>: <jdoc include type="section"....>. It should be a container for modules. In the properties of this container it should be possible to assign a title (name) using the aria-label and aria-labelledby attribute and the header (accessible name).

@chmst
Copy link

chmst commented Apr 22, 2020

Wouldn't it be better to add an input field for the section name in module parameters? This xould be easy.
Modules can be defined as sections.

@zwiastunsw
Copy link
Contributor Author

The programming can be solved differently. Of course, it can also be a new module (e.g. Section Module), which has additional parameters.

@brianteeman
Copy link

Surely getting the admin ui accessible has a much higher priority for the beta release than a front end template that people wont be using (yes I do understand people will learn from it). @chmst and myself have been working alone on the admin for the last 12+ months and I know there is still a lot that can be improved etc before I would even look at the front end

@carcam
Copy link

carcam commented Apr 22, 2020

@brianteeman thank you very much for your insights. We are also working on backend template, but his template is also in our team goals.

Stay safe and healthy!!
Best!!

@hans2103
Copy link

hans2103 commented Jul 1, 2020

@zwiastunsw

  1. only one area can have the role of a banner (header tag; a page can have only one page header),
  2. the banner area (header tag ) must be the top level area (landmark),

copied from : https://www.w3.org/TR/wai-aria-practices/examples/landmarks/banner.html

  • The HTML header element defines a banner landmark when its context is the body element.
  • The HTML header element is not considered a banner landmark when it is descendant of any of following elements:
    • article
    • aside
    • main
    • nav
    • section

My conclusion: there is no need to add the attribute role="banner" to the header element on https://github.com/joomla/joomla-cms/blob/16f284fa7852c6f081da9dde4ef01c90a75e862d/templates/cassiopeia/index.php#L97

Do you agree?

@hans2103
Copy link

hans2103 commented Jul 1, 2020

@zwiastunsw

  1. only one area can have the contentinfo role (footer tag; a page can have only one page footer),
  2. the contentinfo area must be the top level area (landmark),

copied from: https://www.w3.org/TR/wai-aria-practices/examples/landmarks/contentinfo.html

  • The HTML footer element defines a contentinfo landmark when its context is the body element.
  • The HTML footer element is not considered a contentinfo landmark when it is descendant of any of following elements:
    • article
    • aside
    • main
    • nav
    • section

My conclusion: there is no need to add the attribute role="contentinfo" to the footer element on https://github.com/joomla/joomla-cms/blob/16f284fa7852c6f081da9dde4ef01c90a75e862d/templates/cassiopeia/index.php#L176

Do you agree?

@hans2103
Copy link

hans2103 commented Jul 1, 2020

  1. only one area can have the main role,
  2. the main area must be the top level area (landmark),

Small steps... I have created a PR to implement the main landmark to Cassiopeia template
joomla/joomla-cms#29870

UPDATE

PR is merged in Joomla 4.0-dev

@zwiastunsw
Copy link
Contributor Author

Yes, I agree. there is no need to add the attribute role="banner" to the header element and the attribute role="contentinfo" to the footer element. Thx for your involvement

@hans2103
Copy link

hans2103 commented Jul 21, 2020

When chosing Module Tag other than div when configuring a module the styling of cassiopeia fails.
To fix this I have created a PR joomla/joomla-cms#30160

After that we can continue to adjust the sampledata plugin and set module_tags aside, nav, and section` to the Sample Data modules.

UPDATE

PR is merged in Joomla 4.0-dev

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants