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.
Related
I am trying to select a dynamic calendar on a website. My goal is to open the calendar and input dates as I need to. I am not able to open the calendar by "Press button on web page" or "Click link on web page" with my selected UI Element. There are no ID's available to select. I have tried using the div class names with no luck. I have tried altering the selector to make a custom selector that looks for div names containing part of the class name. The 'Name' attribute in Power Automate is unavailable for the UI Element.
After trying all this, I noticed an Icon that is part of a div for the calendar, has
aria-hidden="true"'. When I checked the MDN here it has a warning statement: "Warning: Do not use aria-hidden="true" on focusable elements."
With being unable to select the calendar with standard and custom selectors, am I being blocked by the accessibility setting? Is Power Automate unable to focus on the calendar opener from aria-hidden="true"?
I don't know power automate, but what you observe makes sense. The attribute aria-hidden=true tells assistive tools such as screen readers and voice control software to ignore the element, as if it wasn't present at all.
A focusable element must never be aria-hidden=true. A screen reader won't know what to say when landing on it, and, as observed, it won't be reachable using voice control.
That's simply a pure accessibility fail (I would even call it stupidity, but well).
Technically, the solution is very simple: remove that stupid offending aria-hidden=true. Those who made that calendar probably put it there because:
they thought that screen reader and voice control users will always enter a date by hand and won't ever use the date picker
the date picker hasn't been made accessible, and so it's better to ignore it completely rather to present something only partially accessible
They copy/paste the code from elsewhere and didn't pay attention
They have no excuse for the third one, and for the two first, both reasoning are just wrong. Even if it isn't perfect, it's better to have a little something rather than nothing.
Keyboard-only user or screen reader user don't necessarily mean eased to enter a date manually. ON a mobile, the virtual keyboard is often painful to use, and people with limited movement sometimes use a device with only a few available keys (such as enter, tab, escape, and arrow keys only). Additionally, both might be combined if you think about someone who has a strong dyslexia and an inability to use his hands (the device would be actioned with feet, blinking eyes, etc.).
In theory, you shouldn't ever use custom widgets if you can avoid it. For entering dates, the standard exists: input type=date and friends.
Using standard widgets is the best guaranty to have something accessible at long term. Even if it might not be 100% accessible right now, it's getting better as the time passes.
Sadly, UX designers often don't like standard widgets much because it doesn't look like what they want, and there are still a few older browsers which don't support them all very well.
i have a few buttons on my site with audio playing on button hover.
i have main sound on/off toggle button on my navbar.
my question is if it's accessible to play an audio on mouse hover and not on button click? since the user doesn't expect to hear sound when hovering on an element.
i can't find anything on wcag site about play on hover. nothing but this https://www.w3.org/TR/WCAG21/#audio-control
What an interesting question!
Short answer
Don't play sounds on hover automatically without the user explicitly setting the sound to "on" on the site first.
This isn't just an accessibility issue this is a user experience issue, playing sounds without asking permission first is a terrible practice as your user may be reading your page in a library or on a train and will not expect sounds.
If you really want sounds on your site I would suggest a popup on site load that allows a user to enable sounds if they wish.
Longer Answer
Does playing a sound on hover break any rules in the WCAG?
There is no specific guidance as far as WCAG is concerned as to whether a sound can play on hover.
However there is a lot of general guidance that is very closely related that although doesn't specifically mention this scenario is close enough that we can infer whether or not this is a good idea.
I would recommend referencing guidance G170: Providing a control near the beginning of the Web page that turns off sounds that play automatically, guidance G60: Playing a sound that turns off automatically within three seconds and guidance G171: Playing sounds only on user request
You will see there is a common theme, give users the choice as to whether they want sounds and if you do play sounds automatically make sure they don't last more than 3 seconds.
There is also one other thing to consider
The unspoken rule(s) of accessibility
These aren't hard and fast rules but in accessibility there are two things applicable to this question you should always strive to adhere to.
1. Follow Expected practices
Navigating the web I expect to see certain things. If I click a link I expect the page to change, if I click on a picture I expect either nothing to happen or that image to pop up in a lightbox or open in a new page.
Expected behaviour is a key part of accessibility for all sorts of people with disabilities, but especially those with anxiety disorders and those with cognitive impairments.
Having a sound play on hover could startle, scare or confuse certain people or be very distracting for others (e.g. someone with ADHD or Autism).
2. Try to offer the same experience to all users.
The other thing you are doing wrong is offering a different experience to different users.
If someone has mobility issues / accuracy issues (e.g. Parkinson's Disease or Cerebral Palsy) then they may use a keyboard instead of a mouse and will not hear the sounds that mouse users experience on hover.
For this reason if you implement sounds make sure they fire on both the focus state and hover state.
So with all of the above in mind what should you do?
The simplest answer is not to have sounds at all, but you may have a good reason you want sounds on hover / focus.
So the first thing you should do is give your visitors a choice when they first land. Do they want sounds on the site or not.
Instead of switching it on automatically people should explicitly tell you that they want sounds to be played on the site. If they dismiss the message assume they do not want sounds.
This will also help screen reader users etc. as not every screen reader user uses a keyboard (for example someone with severe Dyslexia may hover over items to have them read out loud, your sounds on hover would interfere with that).
The second thing you should do is make sure that no sound plays when over your switch to turn sounds off (in case someone switched them on by mistake), or at least make sure that sound is less than 3 seconds if you really must have a sound. For all other buttons / links etc.
I would probably say make sure sounds last no more than 3 seconds, although one scenario where this may be allowed is if hovering a link previews an audio file. If this is the case I would make sure that when someone decides to enable sounds it is clearly stated that some links may play audio for more than 3 seconds.
The final thing you should do is make sure that sounds are played on hover and on focus. You should give your keyboard users the option to enjoy the same experience as mouse users if they want.
Finally - reconsider using sound. It is likely just going to annoy your users anyway as hearing a sound every time I hover an interactive element is soon going to get frustrating if I have been on your site for more than a minute.
Obviously there will be valid use cases for sound on hover, but there are probably very few of them.
Accessibility is important to me as I'm a physically disabled developer. I'd like to make sure I have a good feel for what it takes to make a site accessible while also being pointed in the right direction for the things I'm uncertain with, or just haven't considered. So, here's what I'm comfortable with right now:
Alt text for images with meaning.
Percentage or font-relative measurements (ems) for those who need to re-size their screens.
Colors with good contrast for those with colorblindness.
Textual representation of any audio/visual material.
Questions:
Should I make a link at the top of the site to jump down to content on every page?
How is JavaScript handled by screen readers?
Is there anything major I'm missing?
WebAim.org is a great resource for all things web-accessibly related. Suggest starting off with their WCAG (Web Content Accessibility Guidelines) checklist.
Quick answers to your qu's:
Should I make a link at the top of the site to jump down to content on every page?
This is currently recommended best practice. (Eventually HTML5 semantic tags will remove the need for this, but we're not there yet. One thing to watch for: if you do use a hidden link, be sure to make it visible again when it has focus, so that sighted keyboard users don't get 'lost'.)
How is JavaScript handled by screen readers?
All depends on what you use it for. The main area for problem is if new content appears that the user is supposed to be aware of (eg. popups, expanding blocks); if it doesn't get keyboard focus, a screenreader may not read it out to the user and the user may not realize that anything has changed. This is one area where it may be necessary to test with a real-world screenreader (eg. NVDA or JAWS) to ensure that it's actually usable. A simple approach is to only have UI appear in response to user request: eg user hits return on a menu item to make the menu appear, don't make it appear merely in response to it getting focus. Then when it does appear, set focus to the first item: this is both expected behavior for menus in most UIs, and changing the focus typically also causes the screenreader to read out the new item, which confirms to the user that something has happened. (Also, if using Javascript to add behavior to existing elements - eg. make a link behave like a button - use WAI-ARIA attributes such as role="button" to let the screenreader know what the intent is so it will read out that role to the user, and will say 'button' instead of 'link'.)
Is there anything major I'm missing?
I think you've got most of the key points already covered above; the WCAG checklist should fill in everything else. One major area that is worth mentioning is to use headers (H1, etc) appropriately. For screenreader users, navigating by header is a major way for navigating a page. Typically when navigating to a page that a user hasn't visited before, the user will hit a hot-key to get the screenreader to bring up a list of headings on that page as a way of 'skimming' to get an overview. Having good link text is also important; ideally links should be self-describing, so you don't just hear "click for more", "click for more" as you tab through a page.
For newer browsers, IE8, IE9, Firefox 3?, and Safari 5 (possibly 4), and newer screen readers WAI-ARIA is the way to go. Among other things it has landmark roles which if you have an ARIA reading screen reader, such as JAWS 12 and possibly JAWS 11 and 10, the screen reader can use to jump around. It can get a bit clunky if you want things to be backwards accessible but is the direction the web is going in. Their are many other advantages to ARIA but that's the one relevant to your question. On a related note VoiceOver for the Mac is supposed to be ARIA compliant as well.
I'm not disagreeing with the selected best answer, but I would spend more time learning about WCAG 2.0 than with the original WCAG specification. Both in the United States and internationally, the Web Content Accessibility Guideline 2.0 are quickly becoming the standard. In fact, the Access Board, the group tasked with defining the guidelines for Section 508, are refreshing the standards to be harmonized with WCAG 2.0.
You can find great information by starting here Web Content Accessibility Guidelines (WCAG) 2.0.
How to Disable print, print screen, right click using asp.net
You cant. You cannot avoid content being copied from your pages.
Disabling Right Click is possible, but it doesnt solve your 'problem'. The user could still copy your image, by disabling javascript or just inspecting the source.
And even if you could disable those keys, the user could still just make a photo of his monitor. Good luck disabling that!
Short answer: You don't. You are writing a web application; features of the underlying platform are outside your scope, and you have no business trying to fiddle with them.
Long answer: You can try to capture those keys using javascript, and override the default behaviour, which will somewhat stop very naïve users, but all it takes to disable this "security" is to turn off javascript. Even if you come up with more sophisticated "protection", the essence remains: You are sending content to the client, and once it gets there, it is out of your hands. Given suitable tools (wget is enough for most things), anyone can copy and modify your content in any way they like. Similarly, whatever can be shown on the screen inside a browser can be captured and saved. There is no way around it. If you don't want your content copied, don't send it.
Forget about it. You will irritate your end users who will find a way to con you and do what you didn't want them to do. Forbidden fruit is always the sweetest. By telling them explicitly "you cannot do this", they will wonder why do you want to guard your content and they might try even harder to do stuff you otherwise wouldn't want them to do.
Psychology and technology are against you in this case.
Printing
You could disable printing (well sort of - it's not 100% effective) using a "print" style sheet.
I have not tried it myself, but here is a link that could get you started: http://webdesign.about.com/od/advancedcss/qt/block_print.htm
Print screen
Print screen is something that is typically controlled by the operating system not the browser nor webpage. So you are unlikely to be able to stop this. However, casting my mind back I remember a time (perhaps a long long time ago), where you couldn't take screen shots in Windows (maybe Windows 98) of videos... so if your really in need of disabling print screen - perhaps you could perhaps encode your content in a video... but this will have many many downfalls - namely accessibility, search engine optimisation and it being a royal pain to do... so I wouldn't recommend it under any circumstance.
Right screen
Right click you can disable, but not using a server-side technology (such as ASP.net) instead in a client-side technology such as javascript. A quick search in your favourite search engine will find some help. But disabling right click is rudimentary to get around, so it is not full proof.
An alternative to protect your content is to possibly investigate "rights" in PDFs. I believe you can disable the "right" to print.
However none of these solutions are going to be full-proof. As long as you are making your content available to an end-user on their own computer, there is always going to be a way around your restrictions.
I have implemented for disabling printing using window.onbeforeprint()
Refer this Answer
I'm having problems making FullCalendar fully accessible. I'm using the default month view and can't access the next, previous, and today buttons on the top right without using a mouse. If I run a screen reader, I can access those buttons but not without running the screen reader.
And on another note, I currently am using tool tips that pop up when you mouse over an event title to display more information. If anyone has any tips on how to make those accessible to a screen reader or accessible without a mouse, I'd greatly appreciate it!
Regarding the buttons, I would advice that you write new buttons if accessibility is important. These buttons you could then hook up to your own javascript functions that moves to previous and next.
Check out this documentation example
Regarding the second problem, I think that's the same problem not just for physically impaired but also for things like mobile browsers. My tip would be to avoid onmouseover if the information that appears is really important.