I have a presentation that I have been told to use. When in presentation mode, each page builds one bullets at a time.
I want each page to show all bullets at once as soon as the page is shown.
I think I've found how change this behavior one bullet at a time, but that's going to take forever to change all of them.
Can I change this behavior in some global or "all at once" way?
Related
I have a personal website and I want to spice it up a bit while also learning some front-end.
An idea I had was that the cursor of my website would be a coffee instead of the default one, and anytime I click on any content, the coffee pours.
Any idea if this is possible and if so, what I need to do to implement it?
You can change the cursor using CSS - see https://www.w3schools.com/cssref/pr_class_cursor.asp and do something like
div {
cursor:url(myCoffeeJug.cur),auto;
}
You could then use Javascript to change the cursor shape (ie URL) when the user clicks in the div. You'd need to think how to change it back again after whatever operation the click triggers is complete.
Note that you can't do animations this way - but given that clicking on a div is likely to be quite a quick action, just switching to and back from a different icon might well be enough for what you want.
However this is perhaps not a great idea from the usability point of view. Web users are used to the basic types of cursor provided by browsers - overriding them may be cute, but it can also be confusing.
If your site is designed for 'ordinary' users looking for information or functionality (rather than for web designers, or as a showcase for your techniques), you're putting a small barrier in their way. Users who are not confident, or are new to all this, or non-neurotypical users may find it off-putting.
The website of PageSpeed Insight is the only place, where i get CLS issue in both of field and lab data.
Any other Lighthouse instance (by WPT, as API or by DevTools) displays CLS issue only in field data, not in the lab.
How can i diagnose correctly, which elements are causing CLS? Example.
PS: My question has the following cause: analyzing other websites i usually have under devtools → performance red diamonds layout shift, which, if clicked, display in tab Summary some data about this layout shift. Like on the screenshot:
But on the example site i get CLS diagnosted, but not displayed.
The synthetic (lab) tests only load the page (they do not interact with it), whereas field data is until page unload.
Immediately I can see one Layout shift is when you open either of the drop down menus, your scroll bars disappear (due to adding the class .overlayed) and the whole page shifts around. Synthetic tests do not open the menu so will never capture it, however this shouldn't actually contribute to CLS as it requires interaction to open (just something to fix).
The other thing I noticed is the bottom right corner icons cause a layout shift when you scroll and they collapse / open (the floating icons). This is likely to be the cause of CLS as it isn't via direct interaction. Scrolling does not count as user interaction when it comes to CLS.
My guess is that this is the one that gets found by synthetic tests sometimes and not others.
Finding Layout Shifts
In order to find layout shifts you can open developer tools, go to rendering panel (you may need to open it with "more tools") and click "Layout Shift Regions" so it is selected.
Now use the site and you will get a blue box around anything that shifts.
Or you could use performance traces
The other way is to run a performance trace in the performance tab and then just use the site. Once you are done complete the trace and it will tell you if a layout shift occurred and what item caused it.
Tracking them in the field
In order to capture layout shifts in the field yourself you should use something like Google Web Vitals library along with click / mouse position tracking etc and pipe it to your own backend or Google Analytics for analysis.
This lets you find issues with the page a lot more quickly and easily using Real User Metrics (RUM) data in real-time.
Tab trapping is a fairly well established pattern (example). Typically for the sake of accessibility, it allows keyboard users to navigate inside dropdown menus and modals. What's concerning however are the implications for users now that the native functionality of the tab event has been overwritten with a new behavior (looping). This isn't a big deal for sighted users, but it is problematic for users of Assistive Technologies like NVDA and JAWS that critically rely on that native tab functionality.
WAI-ARIA has a solution for informing Assistive Technologies of when native keyboard functionality has been overwritten in the form of aria-role="application":
Keyboard interaction is completely under the web author's control and
can be anything associated with the particular widget being
implemented. In a slides application, for example, a widget could be
created that uses the arrow keys to position elements on the slide,
and uses audio feedback via an ARIA live region to communicate the
position and overlap status with other objects. Focus is being managed
via aria-activedescendant.
The tab , Space and Enter keys, as well as Escape , must be handled by
the application. The one exception is if focus is set to a standard
widget inside the application that supports keyboard navigation from
the browser, for example an input element.
This would imply that any component that employs tab-trapping should necessary have a role="application", always.
However I don't believe this common practice. Sites like Target.com for example (that use tab trapping on their dropdown menu) categorize it as a list, as seen here in the website Accessibility Tree:
I'd appreciate any experienced perspectives on this. Am I interpreting ARIA correctly here? Should components that employ tab-trapping always be decorated with role="application"?
Short Answer
You do not need to add role="application" provided you set the menus up as modal dialogs. With other patterns it may be applicable (highly unlikely, role="application" is a very specialised role) but at that point you probably implemented the wrong pattern in the first place.
Longer Answer
The loop pattern is fine as long as implemented correctly (and target.com did a pretty good job)
There is nothing wrong with this pattern as long as it is implemented correctly (which target.com seems to surprisingly do a quite good job of, just a few things they could do better).
Using 'target' as an example, you will notice that when you click on 'categories' for example the revealed menu actually gets treated like a modal dialog.
It has role="dialog" and the 'button' that opens it has aria-expanded.
They also trap tab focus within this modal and provide a 'close' button that appears at the bottom of the list if you are using the tab key.
All good so far, nothing wrong with looping within a modal dialog as that is expected behaviour.
They also get a few other things right, once the 'dialog' is open you cannot access any other content. For example in a screen reader you may press the keys 1-6 to find the next heading levels, you cannot do this while the menu is open as they apply aria-hidden="true" to everything outside of the menu modal (a true modal trap).
Also you can close the menu modal and focus is returned to the menu item that opened it in the first place, so they manage focus correctly too.
Finally you can close the menu modal with the Escape key, which is also expected behaviour.
So if you wanted to follow this pattern for your menus I would say go for it, they are accessible as they are and a screen reader user would not struggle using them.
What can we do better than target.com
Target got the basics right, they are just missing a few key steps.
The 'button' that opens the menu should have the aria-controls attribute just to link that together properly.
The menu items within the menu dialogs should all have <nav> elements around the <ul> (although arguably as these modals should only be accessible via the menu button this association is implied and this is a minor point).
The arrow sprites they use have focusable="false" which is good but they didn't add role="presentation" or better yet aria-hidden="true" so they do get announced if your screen reader is set to verbose. (aria-hidden="true" is preferable as support is better).
The menus themselves should not really be multi-layered. i.e. if you click 'main menu' at the top of the list it then becomes confusing as to where you are, am I still within the modal dialog? Additionally this is implemented in a way where it does not announce the first item in the 'main menu' list once you follow the link (timing issue maybe?) so it is disorientating. This is the biggest problem with their implementation.
There are other things but you get the idea, if your menu is just a single list per 'drop down' (modal), the way this is implemented is perfectly acceptable and usable and better than a lot of menu implementations I have seen.
So should I use role="application"
No.
Seriously, you will probably never need to use this during your career and it's use can break a lot of accessibility.
Oh you want more detail? No problem!
No you do not need to use role="application" here, in fact you would introduce a lot more accessibility issues doing so.
role="application" implies that all the controls are custom and that you should disregard the standard website controls. (you are basically telling the user / screen reader 'treat this like a desktop application where shortcut keys will be explained via the menus etc.' and 'expect some strange behaviour that is not associated with websites, do not rely on your normal keyboard shortcuts as they probably won't work')
As this follows a standard web pattern (trapping focus within a modal) adding role="application" would actually confuse people.
You mentioned about the Tab looping, but within the list it functions as expected (pressing the down arrow at the end of the list does not loop) so the Tab looping only occurs within the modal.
I think the following quote for the page I linked on role="application" summarises the important information. I have added bold for emphasis on the key points that are applicable to your question and added comments after if appropriate.
The application role indicates to assistive technologies that this
part of the web content contains elements that do not conform to any
other known HTML element or WAI-ARIA widget. Any sort of special
interpretation of HTML structures and widgets should be suspended, and
control should be completely handed over to the browser and web
application to handle mouse, keyboard, or touch interaction.
In this mode, the web author is completely responsible for handling
any and all keyboard input, focus management, and other interactions
and cannot assume assistive technologies would do any processing on
their end.
So basically if you added role="application" you would then not get the native behaviour of any element, this would introduce a lot of work! (in practice most screen readers will still allow basic functionality, but they do this because people misuse role="application")
If the web application encompassed by the application role contains
parts that should be treated like normal web content, a role of
document or article should be used.
So you would have to add role="article" or role="document" to the lists, the close buttons etc. Basically the whole thing would have role="article" anyway (as that would be the most appropriate role).
Unless you are building very complex software, role="application" should not be used.
I developed a CSS-based layout for a web application that has been locked down and awaiting back-end integration. The primary element on the page is a timer/clock.
As originally intended, the timer is just a timer and is very simple. It looks like this:
Now, the boss has asked me to make a pretty significant change to my design. They want 3 tabs to hang off the bottom of the clock. They did not want this before, so I didn't build any show/hide logic and I didn't build tabs under the clock either. I am also slightly concerned because the tabs are at the bottom of the clock - that seems like a point of curiosity but I am guessing it is not huge problem either. Clicking on any of the tabs needs to cause the tab that was just clicked on to have focus, and it would cover the black rounded rectangle and display information about the tab the user clicked on. It would cover the clock. I would describe their request as reasonable, but I wish I'd had this requirement when I was coding. I think it sounds like a relative of a show/hide toggle. This is how they want the tabs to look, and where they want the tabs to go:
The part I am getting stuck on is how to slipstream something like this into what I've already created for the clock. Effectively they need me to make that component much more interactive, as the tabs have quite a bit of functionality within them. There are 3 tabs that I envision needing, but the mockup only shows 2, and that's ok.
I've included a few images in this post and I hope it helps. I've spent nearly a week smashing my head against this and I am stuck. To sum it up, I need to introduce (or shoehorn) a show/hide component as part of a late-hour change.
I am decent with CSS/JS/Web dev, but this is my Achilles heel. By "this" I mean taking a part of the UI that I already created and making it behave totally differently. In this case a pretty simple timer needs to change and has to have tabs at the bottom of the clock that would cover the clock itself when clicked. I hope I was clear enough in this question.
You have a very simple way to resolve this, using JQuery (you can use Javascript on it's own, but this will make it easier for you, less writing).
The give an ID to the DIV where you have the HTML for the clock, move the entire HTML content into a declaration like this:
$("#myDivId").html("put all the HTML content here, don't worry with the size of it");
you just need to change the HTML based on what you want to display. For easier implementation you can create a variable for each different content options, like this:
var myFirstHtmlBlock = "<p>blah blah blah</p>";
var mySecondHtmlBlock = "<span>Anything else...</span>";
and then change the content using those variables:
$("#myDivId").html(mySecondHtmlBlock);
Just let me know if this sorted out your issue.
I'm facing a weird problem in wordpress. Every change I make in content and all others except "Theme Design" works great. Every change I make in "Theme Design" it takes almost endless time like when I first made change and then I keep trying on changing and saving different settings of Theme Design, it took almost 2 hours to show my change, same thing happened next time.
I'm using "venedor Green-pink" Theme.
This is my web on which I'm working on: http://www.teuscherchocolate-oc.com/
Background of header is transparent, I made this change 5 hours ago, now I've changed the background to grey color but the changing is not showing up.
It sounds more like a browser issue. When logged into wordpress you should see all changes, even to a simple stylesheet, etc. However, outside of wordpress it could take an undefined amount of time for a browser to clear it's cache automatically for a new stylesheet it doesn't know is updated.
You could consider adding version numbers to the files responsible for your Theme Design changes. In other words, find what styles are being updatted and where. Tack on ?v=1 to the file.
If you clear your cache, do the changes show?