I am running accessibility testing using the cypress-axe plugin with cypress and storybook. The cypress-axe plugin continually gives false positives when having made the required changes.
The false positive is for page-has-heading-one but I clearly have a h1 element present in the screenshot.
False Positive screenshot
Cypress version: 6.1
cypress-axe version: 0.12.0
Here's the html for the element in question:
<div role="main"class="example-slider">
<h1 role="banner">Slider</h1>
<mat-slider
min="1"
max="50"
step="0.5"
themePalette="primary"
id="slide"
value="1.5"
aria-label="slider"
role="contentinfo"
>
</mat-slider>
</div>
Thank you ahead of time if anyone can help with this.
Not a false positive.
The second you gave the <h1> a role you changed it's semantic meaning.
role="banner" is effectively the same as <header> in HTML5, so you have changed your <h1> into a <header> element as far as a computer and assistive technology is concerned.
Remove that role="banner" from your <h1> and it will work as expected (and be semantically correct).
Also while you are tidying things up <div role="main" is the same as <main>, you should always try to use semantically correct native HTML elements where you can as they will make your mark-up cleaner and they have wider support.
Related
I'm trying to create a fixed Navbar using Project Clarity
I'm using it in my Angular project, they are using FlexBox, I have tried putting in position: fixed but it doesn't seem to work, anyone have any ideas ?
<clr-header class="header-6">
In order to fix the header so that content scrolls underneath it, your application needs to have the correct Application Layout. Our components work within this structure because A properly structured layout enforces an optimal, consistent experience across applications.
The general structure for A Clarity Application layout takes this form:
<div class="main-container">
<div class="alert alert-app-level">
...
</div>
<header class="header header-6">
...
</header>
<nav class="subnav">
...
</nav>
<div class="content-container">
<div class="content-area">
...
</div>
<nav class="sidenav">
...
</nav>
</div>
</div>
Obviously, you can get rid of the parts that may not be relevant to your app like: alert-app-level, subnav etc ...
You can see this working in a quick demo I made with inspiration from Bob Ross. As you can see the content scroll underneath the application header.
if someone has also either very this problem, or another problem where some css does not work within Angular:
Since we mostly structure our UI code in multiple components in Angular, and since each component puts its own host-tag in the generated DOM between the actual html tags, the clarity library has some problems with it.
So as a workaround, if you still want to be able to keep your current htmls as they are, you can define this css in each your component's css file:
:host { display: contents; }
This causes the component's box not to render; means the host tags are still visible in DOM, but they will not have any effect regarding CSS. And any clarity CSS will work again.
I am trying to add 3 columns to my ionic navbar and it does not work.
Here is my code:
<ion-nav-bar class="bar-dark nav-title-slide-ios7">
<ion-nav-back-button class="button-icon ion-arrow-left-c">
<div class=row>
<div class="col"> Andreea </div>
<div class="col"> Kate</div>
<div class="col"> Andi </div>
</div>
</ion-nav-back-button>
</ion-nav-bar>
Any idea what I am doing wrong?
Would you rather do it as a list (ul, li)?
Thanks!
You may consider using ion-header-bar instead of ion-nav-bar since it allows for quite a bit more customization. (It will work with multiple columns such as those in your code.) You would, however, lose the ui-router integration built into ion-nav-bar which would require you to handle said navigation yourself. See this page for further explanation: Navigating Ionic's Headers. Here's the gist from the article's conclusion:
A standard header bar serves on its own as a pure UI element, ready for extension based on the developer’s needs, but doesn’t come with the advanced integration into Ionic’s router and navigation stack. The nav bar is far more opinionated in its use, but offers a lot of power in return.
I'm currently building a WebApp with the following structure :
However, I'm not often developping for Web, and I would like to know what HTML tags I should use to enclose the different sections of the app.
Should I use <header> tags for the header bar, <nav> for the menu, <aside> for the notifications and <article> for the body, or something else? (I'd appreciate it too if you can give me some kind of skeleton for this)
I don't think anyone actually does it any standard way, but I really recommend looking into smacss -- scalable and modular architecture for css. https://smacss.com/book/type-layout It's a great philosophy on how to organize and name css/html.
Following smacss, you will divide your content based on header, footer, and article. whereas navigation is a child element of either header or article, so you can either choose to use the tag (if the navigation will remain constant throughout your entire web structure), or if it'll be flexible and changing, you should stick to labeling the navigation a class or id, and not use the tag itself (this is to ensure you can reuse as much css as possible... read the entire smacss article for more on reusing css and further reading on oocss -- object oriented css)
Yes, I believe you are on the right track.
Personally, I'd use
<header id="site-header">
<nav id="menu">
<section id="main">
<aside id="notifications">
While your use of article is not wrong for sectioning, I like to think of layout as the division of a page into sections. And then, within the main section, there may be many articles - possibly with their own headers, footers, sections etc.
I also like to use ids for each important part of the page - on top of making the content semantics even clearer, id also makes it much easier (and faster) to find and select them using JavaScript.
Just a minor note: I'd avoid calling the main content section "body" simply for the reason that it can be confused with the <body> tag.
Just use them like you have listed above. It's worth just referring to this handy guide to ensure your chosen tags work cross browser (See and for an example).
There is no wrong or right answer.
The use of the HTML5 tags such as header,nav,footer,aside,section can help you and other developers better understand your structure .Here is sample . you can go to the link to see how it is used !
<!DOCTYPE html>
<html>
<head>
<title>Title of the page</title>
</head>
<body>
<header>
<h1>Here is <span>HTML5</span> Page</h1>
</header>
<nav>
<header>
Navigation menu
</header>
<ul>
<li><span>Blog</span></li>
<li>About</li>
<li>Contact</li>
</ul>
</nav>
<section>
<header>
<h1>Blog posts for April 2012</h1>
</header>
<article>
<header>
<h1>Information about this example</h1>
This example is a modified version of http://netstream.ru/htmlsamples/html5-blog/index.html
</header>
<p>Try to move the mouse on different elements. The structure will be highlighted and you will be able to see the different inclusions of elements one in each other. If you move the cursor to this sentence, it will be highlighted in dark grey, showing the presence of an <article> element, surrounded by a <section> element (light grey), etc. So we have some articles in a single section element. The page title at the top is a <header> element, while the tag cloud on the right is a <aside> element. The main menu on top (with Blog, About, Contact) is a <nav> element.</p>
<figure>
<img src="http://www.fredcavazza.net/files/2009/09/html5_structure.png" alt="Example of HTML5 structuring tags" />
<figcaption>
Fig. 1 : an example of how new structuring elements could be used. This page put a <nav> on top, and does not have headers and footer for each article, like in this figure, but it could... By the way, this is a <figcaption> inside a <figure> element...
</figcaption>
</figure>
</article>
<article>
<header>
<h1>History</h1>
</header>
<p>Work on HTML 5 originally started in late 2003, as a proof of concept to show that it was possible to extend HTML 4's forms to provide many of the features that XForms 1.0 introduced, without requiring browsers to implement rendering engines that were incompatible with existing HTML Web pages. At this early stage, while the draft was already publicly available, and input was already being solicited from all sources, the specification was only under Opera Software's copyright.</p>
<p>In early 2004, some of the principles that underlie this effort, as well as an early draft proposal covering just forms-related features, were presented to the W3C jointly by Mozilla and Opera at a workshop discussing the future of Web Applications on the Web. The proposal was rejected on the grounds that the proposal conflicted with the previously chosen direction for the Web's evolution.</p>
<p>Shortly thereafter, Apple, Mozilla, and Opera jointly announced their intent to continue working on the effort. A public mailing list was created, and the drafts were moved to the WHATWG site. The copyright was subsequently amended to be jointly owned by all three vendors, and to allow reuse of the specifications.</p>
<p>In 2006, the W3C expressed interest in the specification, and created a working group chartered to work with the WHATWG on the development of the HTML 5 specifications. The working group opened in 2007. Apple, Mozilla, and Opera allowed the W3C to publish the specifications under the W3C copyright, while keeping versions with the less restrictive license on the WHATWG site.</p>
<p>Since then, both groups have been working together.</p>
</article>
<article>
<header>
<h1>HTML vs XHTML</h1>
</header>
<p>This specification defines an abstract language for describing documents and applications, and some APIs for interacting with in-memory representations of resources that use this language.</p>
<p>The in-memory representation is known as DOM5 HTML , or the DOM for short.</p>
<p>There are various concrete syntaxes that can be used to transmit resources that use this abstract language, two of which are defined in this specification.</p>
<p>The first such concrete syntax is HTML5 . This is the format recommended for most authors. It is compatible with most legacy Web browsers. If a document is transmitted with the MIME type text/html, then it will be processed as an HTML5 document by Web browsers.</p>
<p>The second concrete syntax uses XML, and is known as XHTML5 . When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is processed by an XML processor by Web browsers, and treated as an XHTML5 document. Authors are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors will prevent an XML document from being rendered fully, whereas they would be ignored in the HTML5 syntax.</p>
<p>The DOM5 HTML , HTML5 , and XHTML5 representations cannot all represent the same content. For example, namespaces cannot be represented using HTML5 , but they are supported in DOM5 HTML and XHTML5 . Similarly, documents that use the noscript feature can be represented using HTML5 , but cannot be represented with XHTML5 and DOM5 HTML . Comments that contain the string -> can be represented in DOM5 HTML but not in HTML5 and XHTML5 . And so forth.</p>
</article>
</section>
<aside>
<h1>Tag cloud</h1>
<ul class="tag-cloud">
<li>ajax</li>
<li>apple</li>
<li>css</li>
<li>firefox</li>
<li>google</li>
<li>html</li>
<li>internet explorer</li>
<li>iphone</li>
<li>css3</li>
<li>ipod</li>
<li>javascript</li>
<li>jquery</li>
<li>mac</li>
<li>opera</li>
<li>rss</li>
<li>html5</li>
<li>web</li>
<li>web 2.0</li>
<li>web-??????????</li>
<li>windows</li>
<li>yahoo</li>
<li>youtube</li>
</ul>
</aside>
<footer>
<p>© 2009 Some blog</p>
</footer>
</body>
</html>
Having seen the source of one of the Bootstrap Expo sites Tsaa Tea Shop I wonder if what they have done, adding semantic HTML5 tags in between BS classes, would give the site a better semantic value?
Considering they use the section element quite a bit, can this be seen as an accepted and good use of HTML5 tags/elements alongside BS?
Here a short excerpt:
<section class="about-us block">
<div class="container">
<div class="row">
<div class="col-md-8 text-center">
<h2 class="section-title">Welcome</h2>
<span class="fa fa-leaf"></span>
</div>
</div>
</div>
</section>
<section class="quote block">
<div class="container">
<div class="row">
<div class="col-md-12">
<h2>"We loved our relaxing time with great food and beverages..."</h2>
</div>
</div>
</div>
</section>
At the moment I am starting work on a smaller project and have something along the line of a simple one-page layout in mind.
Would it do any good in consideration of semantics to follow this approach?
The Bootstrap is unsemantic by default
Twitter Bootstrap is one of the most unsemantic frameworks on the market. If you put to your code classes like container, form-control or col-sm-2 you just can't be semantic.
But sometimes you don't want to be. You want to be readable, practical and maintainable — and that's why it is made for and it's great in it.
HTML5 tags
Yes, yes. We have all these new, sexy, useful, years-needed HTML5 tags like: article, section, nav, main, header, footer or details… But let's face truth — the section sucks almost as much as usuall div.
Semantic of the section is almost zero. God - it's a tag with display:block that is called "section". The biggest (and maybe only) advantage of it is improving of readability, not the semantics. And that's enough.
Why to still use the new HTML tags
Because:
It's more readable.
It's easier to debug.
It's more modern.
It's a bit more meaningful and consequential.
So, if you face the decision — to use or not to use HTML5 tags, do anything, but do not continue in this div-cancer-that-is-the-web-built-on.
… even minified version of new tags is more readable:
<article><section></section><section></section><aside></aside></article>
<div><div></div><div></div><div></div></div>
Are any of these method good to use to keep the website compatible in all browser while using HTML 5 elements?
Just for example
method 1
<div class="section">
<section>
<h1>title</h1>
<p>text</p>
</section>
</div>
method 2
<section>
<div class="section">
<h1>title</h1>
<p>text</p>
</div>
</section>
In above method I will not write any CSS for HTML 5 tags so layout will not be disturbed.
Edit: my question is specially for Mobile websites because in desktop websites I know I can use HTML 5 Shiv and Modernizer but in mobile still my browser are still in use which don't have support or partial support of JavaScript. and Bandwidth is also an important issue in mobile internet so adding a JavaScript will decrease the performance.
I'm making website for mobile with content management system to update content in future and content will be updated by client using WYSIWYG Editor.
A better way would be to use the HTML5 tags as usual and include the HTML5 Shim by Remy Sharp.
Although semantically both the methods are same, I'd go with method-1 as it correctly separates content from container. (OOCSS principle)
<section>
<h1>title</h1>
<p>text</p>
</section>
This is the content. It represents a section of a document and is meaningful. You can now enclose this in a container (<div>) and style it as per your requirements.
Also, you'd realise that method-1 is more flexible when used in large websites
Personally, I use an HTML reset, use Modernizer to check for features, then shim in things:
if( Modernizr.fontface) {}, Modernizr.canvas, Modernizr.audio, etc.
This is good: http://bit.ly/b5HV1x
By HTML 5 reset, you can define the tags not understood by browsers:
footer { display:block; }
I don't think either of those methods are any good. <section /> should be used for any "section" of the markup that doesn't have a specific tag like <header /> or <article />. <div /> should be still used for layout purposes.