I am developing a web-based menu application targeted solely for Mobile Safari on the iPad (in other words, I am not at all concerned about cross-browser compatability). I have a form select box which contains a number of options the user can choose from to modify their order, which when clicked displays on the iPad as follows: Screenshot
The problem is that this box is not wide enough to show the user the price or even the full name for several options. Smaller names is not a particularly attractive option in this case. Is there any way in which I can either a.) set the width of this box (doesn't matter if it's a Mobile Safari-specific solution!) or b.) make it so that the box grows wider to accommodate the widest option? I can find nothing on Google that deals with my question save for one forum thread with no useful answers.
Javascript is an option, if necessary.
Thanks!
To the best of my knowledge I believe UIKit entirely with the popup. The only advice I could suggest would be to implement it solely in JavaScript. I've had a quick Google and nothing is coming up that stands out as a existing one.
Related
I need to show certain content in a modal/fullscreen panel on small devices, triggered by a button. On large devices, this same content, is just always shown and the trigger is then hidden.
How do you approach this for accessibility?
Currently, I have this setup
<button type="button" aria-expanded="false" aria-controls="filter-panel">Filter</button>
<div class="o-panel" id="filter-panel">Form</div>
Initially, the o-panel is hidden on small devices via CSS (in a media query that targets small devices). I set aria-expanded to true when the trigger is hit, and add an active class to the panel itself, which shows the fullscreen o-panel via CSS. On large devices, I hide the button and always display the content from o-panel via CSS (in a media query that targets large devices), inline, where it is found in the HTML.
Does this make sense for accessibility? My panel doesn't say role="dialog", becuase on large devices it's just content, not a dialog. Is it a problem that my button is hidden on these large devices?
I'm really stuck at what I should do here. If I add role="dialog" to my o-panel, should I remove this property for large devices, where it is actually not a modal?
Or should I move copy/move the content from my o-panel in a div with role="dialog", in case the trigger is hit? I just don't want two copies of the same content.
On large devices you need to do a couple of things.
Hide the button properly
First make sure the button is display:none, not visibility:hidden or anything else or it will still show up in the accessibility tree.
The main (<main>) problem
A modal should appear outside of your <main>.
This is so you can add aria-hidden="true" to the <main> element when the modal is active, so as to stop people navigating outside of the modal on a screen reader. (Screen reader users use headings, links etc. to navigate a page so you can't just intercept the tab key.)
Now I come from a mobile first philosophy so I would say your markup should be mobile first. That means putting the modal outside of your <main> as discussed earlier.
This obviously causes a huge problem on a desktop. You now have the content sat somewhere it shouldn't be.
Because of this you only really have two options here.
Option 1
Use JavaScript to reposition the modal content in a predefined placeholder <div>.
So you keep your mobile first design, then use JavaScript to find the innerHTML of your modal and move it into the body within your holder. Then delete the modal itself just to be sure.
While you are at it I would also delete the button, just in case someone resizes the screen to a mobile view, we don't want a button leading nowhere.
Alternatively don't delete the second content then people can resize the browser, just means a few extra DOM nodes (so as long as your modal content isn't over 100 DOM elements I would say do this.)
If you decide to keep the modal make sure that is also display: none for the same reason as the button, we don't want people accidentally accessing it.
Option 2
Duplicate content.
I know, I know, duplicate content is just, urgh.
But sometimes you just have to put up with it if it is for the best.
By duplicating the content into a div from the start you do get a few advantages.
Advantages
If the user resizes the screen you can just use CSS to switch between views.
No need for JavaScript, great for if your site functions without JS or when your JavaScript fails.
Although it adds page weight it is likely to be better for performance overall, the potential for layout shifts with the first option resulting in a high Cumulative Layout Shift is quite high (although avoidable). With Google putting so much emphasis on Web Vitals I would start considering them now. Additionally you might find you write nearly as much JavaScript as there is HTML if your modal only contains a couple of elements.
Disadvantages
You would have extra page weight due to duplicated HTML.
You may have to adjust scripts etc. to account for the second duplicate item (although this should be minor).
This would still be my preference, Keep It Simple! This is far more robust
Option 3 (for the future)
Client Hints are one way you could solve this, turning responsive design into a hybrid of mobile vs desktop and responsive.
When client hints has enough of a market share you could simply use the header to decide which version of the page to send from the initial request.
You could possibly implement this today if you are willing for 25% of users to see the mobile version of your information on desktop, depends how important the info is.
Other considerations
There are a few other things to consider that you haven't mentioned so I thought I would add for reference.
I already mentioned adding aria-hidden to all elements outside of the modal when it is active.
To future proof your application use inert on items outside of the modal. Support isn't great (none existent!), but every little helps and it is quite likely to get implemented!
You can polyfill it if you want but I don't think it has moved outside of the draft spec yet so we just use it as is.
Also add aria-modal="true" to your modal.
I covered a lot of these points in a bit more detail in this answer if you want a bit more info.
Make sure you include <meta name="viewport" content="width=device-width, initial-scale=1.0"> in your <head> tag.Then in your style, you can play around with
#media only screen and (max-width:620px) {
/* For mobile phones: */
}
You can learn more about the #media rule here: W3Schools Media Rule.
If you have any more questions be sure to ask!
The accessibilitys properties are only aria-expanded="false" aria-controls="filter-panel" don't change it.
Your class and ID names doesn't have any impact on accessibility.
If you only want to show the content by default on large device, and display a call to action to show it only on smartphone device, you could do that with javascript and media-query.
I am Trying to find out the "correct"(best practice) way of creating toggleable sidebar with bootstrap 4. Gone through the examples on the internet and not so sure if those were so good...so If someone can send me related resource links ,it would be great so that I can analyze it.
-I am from android platform so I'm a newbie when it comes to web development but I'm trying to achieve that kind of sidebar like on this side: link -notice: sidebar doesn't change its width(stretching) while changeing the size of a browser -until a point when it jumps over to icons width.
Bootstrap does not have an "official" sidebar implementation so nothing is "correct" here. As long as it works cross-browser/cross-device, anything is good to go.
Regarding the sidebar implementation itself, there are various options:
opens above the content,
pushes the content to the opposite side
squeezes the content
The above options and the array of animation possibilities for:
the sidebar itself,
the menu item containers,
the menu names/labels
and the menu icons...,
...make any attempt at providing an example prone to subjective preference and would render your question off-topic.
Other possible features are
auto-open above certain width,
auto-close below certain width,
reordering of elements,
three-state (full, min and off).
But on topic, the only objective answer to your question is: there is none (official).
As a starter, you might want to take a look at this simple sidebar. It works prefectly fine with v4. Just import the simple-sidebar.css and adjust the calls to match your project's elements.
In the end, the sidebar is all about two containers and applying a class (plus, ideally, some aria- attributes for screen readers). What you put in those containers and how you adjust the contents to look in each element state is all about your own (or the designer's, or the client's) personal preference.
I am really new to HTML and CSS but have created a prototype page to get a reasonable size, look, and feel to fit on a 768x1024 or larger display. I revised it to be used in landscape mode but it's apparent it won't fit in a typical browser window even at full screen with my minimum height and width criteria. The page doesn't contain text; just buttons, check boxes, text, and textarea "widgets". I think that I can fiddle with sizing and make it fit into a window if there is only a top "title" bar with the minimize and close buttons but absent all the other "stuff" such as the navigation bar, tool bar, etc. found in a typical browser.
I do use a couple of web apps that are like this so I know that it is possible. I've searched Google for examples and found popups but none are like this.
My question is: how do I do this, preferably without javascript, and what is this type of window called?
This should help with the minimizing: Is there a good jQuery plugin for a hide effect that looks like minimizing windows in Windows
You're going to have to include jQuery from http://www.jquery.com and call this animate script when the window you want to minimize is clicked.
This will help you with the 'closing'.
https://api.jquery.com/hide/
When you click on an element you can call .hide() on it, effectively closing it from the user's perspective.
I'm working on a new web site that currently is configured as a full height (that is, 100% available browser window) application. In terms of layout, it is something like this - http://stevesanderson.github.com/fixed-height-layouts-demo/pane-transitions-tablet.html.
Our web site does nothing with the actual browser window size, like switch browser into full screen mode. It only uses the available space.
Operationally, this is going to be a semi-internal data entry application. Almost all pages are data entry forms or summary pages
Personally, I think makes a very nice looking app. However, some of the other developers are comparing this design with content in scrollable tags to be the same as iFrames. And as such should be avoided.
Is there any background / best practices information about designing a web site this way?
I personally love sites that choose to do this; I think that it's a great way to use up the available real-estate that you have. My one piece of advice would be to add a min-width and a min-height to your page so that you don't have to worry about your site breaking if the browser gets too small. This will not only improve the overall user experience, but will also prevent future headaches when trying to get your design to work in obscure dimensions.
It looks fine, and at first looks more like a 'real' app. The only weirdness with this sort of thing is that on OSX you get a bit of a bouncy effect when you hit the top and bottom because of the rubberbanding on the scroll. If you aren't sure what I mean, grab an iPhone/iPad/Mac and scroll up and down past the top or bottom of the content.
In reality it shouldn't be too hard to enable or disable this feature, so why not start with it, then revaluate once you have gotten going.
There aren't any good practices or background information that I know of on this subject. Just follow the normal rules of thumb, if it looks good, is light and loads well, and it is usable, why not?
I need to create a dropdown, which can contain 100s of options.
I need a scrollbar to appear and be consistent across all browsers.
Google came up empty: Is there a good URL that describes if this is consistent or not?
I would strongly recommend against having a scrollable select with 100s of options for usability reasons.
With exception of one corner case, navigating (both searching in, and selecting from) that list is a really really hard and very annoying to the user.
The UI design reasoning is that it requires:
Wide mouse gesture (tiring), followed by immediate precise stop (hard to do because of inertia)
Very difficult to use interface of a scrollbar (extra crap points for scrollbar being in the middle of the page instead of on the right side) - see Jacob Nielsen's and others' usual ranting about difficulties of using scrollbars and general evil of anything too long that requires much scrolling.
Eyes need to scan whole page worth of menu up and down and back, all the time. very tiring.
Here is a set of bad examples
[ the corner case is when all the option names are uniformly distributed across the alphabet (as far as the first letter), which allows somewhat-possible keyboard-only navigation in the drop-down via pressing the first letter of an option ].
A proper UI solution is to have a select whose contents are dynamically populated based on a search field - either typed text (think Google's new search box, or browser's address bar) or sometimes checkboxes/radio buttons.
BTW, sub-menu solutions also suck for mouse navigation - minor twitch of the wrist and you lost all of the pointing work.
I apologize that this answer is not an answer to "how do you solve my technical problem", but I am of a very strong opinin that you're solving the wrong problem in the first place.
HTH.
The short answer is no, for the standard HTML select element and the requirements you describe.
However, do you know you can set the size attribute for how many rows are visible at one time? AFAIK this will force scrolling in all browsers, but it isn't a drop down. Like this:
<select size="10">
<option>etc</option>
...
</select>
There is also the possiblity of optgroup to split the options into categories.
If you have many categories you could do what I did on one site and use this jQuery click menu, using the click function to set a hidden field. So now I have a dropdown with sub-categories and it's quite easy to find the right option.