On this page, Material Design seems to specify toggle switch buttons should be placed on the right side of their label.
But on the <paper-toggle-button> page of WebComponents.org, the only available option appears to place the toggle switch button on the left side of the label.
And none of the styling options seem to address this issue.
Is this a fundamental incompatibility with MD or am I missing something? In any event, what is the recommended best practice to comply with the MD spec?
Edit:
Here is an open issue on Github.
And here is an open PR.
So apparently a fix is in progress. I just need to know what is "best practice" in the meantime?
To Materialize <paper-toggle-button>, do not use the installed label feature. Instead, create a separate label that can be independently positioned and styled.
<div class="start">
Auto-rotate screen
</div>
<div class="end">
<paper-toggle-button checked="{{autoRotateScreen}}"></paper-toggle-button>
</div>
Related
I have a Filter component in my app. It is a list of buttons out of which only one is selectable at a time. Once a filter is selected it changes/filters the content in a single panel. What accessibility practices should i make use of in this case to make it more accessible?
It is a very common use case but doesn't seem to fit in directly with any patterns explained in the WAI ARIA examples.
The functionality for the filter, according to me, can fall into one of these patterns:
Tabs, but each tab does not have a separate panel which gets hidden/shown on tab selection, rather just a single panel where content changes dynamically.
Radio Group with Radio buttons, which controls another DOM element.
Select functionality but the style is such that all options are visible at the same time, and the select controls another DOM element.
Any pointers or examples?
It seems to me that aria-controls is a good choice here.
Your group of buttons reproduces what is in fact a radiogroup selection, with only one choice selected.
Using radio elements would be a good approach for screenreader users (you can perfectly customize them to look like buttons of course), and then applying the aria-control on the radiogroup element.
Here is a full ARIA ample, but you can perfectly use native input[type='radio'] elements.
<div role="radiogroup" aria-controls="panel1" aria-labelledby="filter">
<div id="filter">Filter by</div>
<div role="radio" aria-checked="true" tabindex="0">Filter 1</div>
<div role="radio" tabindex="0">Filter 2</div>
</div>
<div id="panel1">
Results here
</div>
This question already has an answer here:
Why are buttons discouraged from navigation?
(1 answer)
Closed last year.
I've been reading up on web accessibility and read that anchor tags should only be used when the user will be taken to another URL without JavaScript. But buttons should be used whenever some other behavior should happen, such as opening a modal.
So I'm wondering if it's okay or expected to have both buttons and anchors in a nav. Something like this:
<nav>
Home Page
About Page
<button>Sign Up</button>
</nav>
Say in this situation the signup button launches a modal or does some other behavior that doesn't take the user to a different URL. Is it okay to have both in the nav? I'm not concerned about styling, I'll make these look consistent, but I'm wondering what's the most correct way to handle something like this?
From an accessibility perspective, using both links and buttons is the semantically correct way to go. The links take you to another page (or somewhere else on the current page) and buttons perform an action. A screen reader user will understand when they hear "link" or "button" in the same <nav> that different actions will happen.
As mentioned in the previous comments, yes, it is completely fine to use both inside your navigation.
If you really want to you can use <a> elements for all, but for the buttons you would include the role="button" attribute which is semantically equivalent to using <button>.
<nav>
Home Page
About Page
<a role="button">Sign Up</a>
</nav>
Yes it's totally fine to use either buttons, anchors or even div inside the navbar however you want you can do it. You just need to be comfortable using css and styling which you say you are. Then you should have no problem. Does that answer your question?
Any flow content elements are allowed in a nav tag, and that includes buttons.
Page has two div elements in columns and my requirement is to resize the left column by selecting one side (right edge).
Below is my HTML code
<div id="leftSide" class="left-panel" >
<div class="left-top-panel">
</div>
</div>
<div id="rightSide" class="right-panel" >
</div>
I know there is css resize property. This is not helping me because using this element can be resized by selecting a corner.
I want to achieve this in my angular2 components. Any help on this is much appreciated.
This sounds like something that would be solved by a library or similar, not by Angular. Angular provides a framework that might allow you to hook into that sort of logic, but I would recommend using CSS/Component libraries to provide you with that functionality.
I am looking for a way to format a section of my page so users can easily copy a small block of text while on a mobile device.
Are there any classes in Bootstrap, some HTML, or a way to format my CSS to make this easier. I know browsers except IE don't like javascript copying text to the clipboard.
Since your question is specific to HTML & CSS for mobile, here are some thoughts.
I find that having large hit areas available on the elements you want the user to interact can help to start with. E.g. paddings on <p>s for example. So when a user starts tap-holding to initiate text selection, it'll more likely fall on the hit area of the paragraph. (A nifty trick is replacing margins with paddings!)
Try to make sure your content that is selectable follow a natural content flow box model. No weird floats or absolutely positioned content or otherwise content that might confuse the selection widget. Make it as document-like as possible!
Read up on the ways that you can control selection, e.g. user-select CSS property - https://developer.mozilla.org/en-US/docs/Web/CSS/user-select
You might want to disable text selection on elements that don't make sense, to help make text selection cleaner on the parts that matter.
Large font sizes are obvious, but maybe not so obvious is very large line-heights is fantastic for making text-selection a little less awkward! It can improve readability greatly on the side as well, my favourite for body text is line-height: 1.6;.
If you use viewport meta tag, make sure they can zoom in to fill the text/paragraph edge-to-edge comfortably when they want to. This can help a lot to get up close, to do the text selection and get tactile with your content.
However, if you do want to try JS, then I would recommend clipboard.js: https://clipboardjs.com/
Think also about what your users want to copy ahead of time, you might be able to do some analytics and allow users to highlight common text. This is done on Medium by the way to lead as a good example.
You could make it so that when they click on the element, all the text is selected automatically, so all they had to do, assuming they're using a modern mobile device, is long-tap and press copy to clipboard.
document.getElementById("TextParent").onclick(function(){
fnSelect("TextParent");
});
So your html would look something like the following:
<div id="TextParent">
Click anywhere in this div to select this text!
</div>
Adding to this, Nexii Malthus has a good point in regards to the hit areas on mobile phones, so maybe try to add some extra padding to the div.
You should definitely try https://clipboardjs.com/.
<!-- Target -->
<div id="bar">Mussum ipsum cacilds...</div>
<!-- Trigger -->
<button class="btn" data-clipboard-action="copy" data-clipboard-target="#bar">
Copy to clipboard
</button>
and activate it using following javascript new Clipboard('.btn')
Look created sample https://jsfiddle.net/gevorgha/fbeof421/
Note
There are some compatibility issues with iOS devices that do not copy target on trigger action, but it selects target and allows user to copy it manually.
I am trying to create a menu using HTML5 ( type toolbar ). It turns out that no browser currently supports the toolbar type. (Thanks Zach for pointing me at this) What would be the best implementation that works for Chrome and Firefox ?
Currently, I am thinking about continuing using the menu element as per HTML5 spec and using CSS to style it as needed and JS to add behaviour.
The following mailing list posting explains the current intent for menus of type toolbar:
Toolbars are nothing more than a with the element name .
There's no magic at all, no special content model, it's all CSS for
styling, you use regular form controls to fill the toolbar.
from http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0264.html
Hence, I am daring to say, that I can use menu for all browsers, even if a browser does not explicitly support the HTML5 semantic of the menu element, because it will still display it as a block since the user agents, I have checked ( i.e. firefox,chrome,safari,ie) , style menu with display:block.
If you're open to using a bit of jquery, and if i understand your question, then a simple
<div data-role="footer">
<div data-role="navbar">
<ul>
<li>Summary</li>
<li>Favs</li>
<li>Setup</li>
</ul>
</div><!-- /navbar -->
</div><!-- /footer -->
would do the trick.
read more about navbar widgets here: http://demos.jquerymobile.com/1.4.1/navbar/
I would take a look at the bootstrap menu, it works (IMO) much like a toolbar, and it's got a wide support on a lot of browsers.
It's also got glyphicons so you can give your buttons icons beside the labels easily