My Qt project needs a chat window similar to Skype. Namely, the chat history window, not where the user inputs his text. I thought of using some kind of HTML view to programmatically add chat text as it comes in from the chat parties.
Some requirements:
It has to be formatted nicely, support for CSS I can apply to it..
I must have scroll control - e.g. autoscroll to the end of the chat when new chat lines come in, even if I'm currently scrolled up for some reason.
it has to allow a full mouse copy, just like skype.
Will QWebView do the hob? I did not see scroll control API, or being able to "append" new text lines. Will I have to re-create and re-submit the HTML using "setHTML" every time a new line comes through?
Any advice will be appreciated.
You may want to consider using either QTextEdit or QTextBrowser. Both of these widgets have support for HTML (though it may be somewhat limited). These widgets will allow you to append HTML line-by-line. They also inherit from QAbstractScrollArea, which provides you with access to their scroll bars. I'm not sure if they will support CSS, but they do support Qt's style sheets, which might work for you as an alternative if you can't get CSS to work. They also provide out-of-the-box copy, cut, paste, undo and redo (though you'll probably want to customize this for your case).
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.
We have a web-based app which uses a side-by-side experience for desktop users where the left side of the screen is a file browser and editor and the right side of the screen is an interactive preview. Users of our app will make constant and iterative changes on the left and and then interact with the preview on the right, switching back and forth many times in quick succession.
Is there a "best practice" for allowing quick and easy navigation between these two interactive areas? I know this might fall under the "opinion" category, but I feel that accessibility is such an overlooked topic that it helps to have as many resources as possible.
You have a few tools at your disposal.
Headings
Headings are one of the easiest ways to bake in some super simple section switching. Screen reader users will use the keys 1 through 6 to navigate by heading levels so if both of your panels are <h2>s (for example) they can simply cycle location using headings.
Keyboard shortcut keys
You can set keyboard shortcut keys.
However you should never do this in isolation. By this I mean if you say that switching window is say Alt + 0 you must allow users to be able to change these key bindings to their preferences.
This is so your shortcut keys don't interfere with their screen reader keys (as they may have set custom keyboard shortcuts).
please note: as pointed out in the comments this is not a WCAG requirement for key combinations (which is only for single keys) but is a usability best practice and highly encouraged, especially as some screen reader users use a modifier key rather than a toggle key for screen reader navigation.
Then we get into an interesting area which I like to illustrate by saying "how would a one handed user use your page?".
This example makes you realise that some sort of sticky keys solution may also be considered where key combinations can be done with a sequence of keys, any time apart (as you may have someone with NO HANDS using eye gaze technology or a switch for example so you don't want to impose a time limit.)
Obviously the above are extreme examples but things you may want to consider (and in reality anyone using eye gaze would be able to visually switch panels etc.)
Voice commands
Being able to switch panels via voice (for example Dragon Naturally Speaking) is also essential.
Now you can do key combinations with voice software so that fixes most issues but they can be annoying and fiddly.
One thing that is quick to use on most voice software is clicking any button on a page with a unique name.
As such having a button above each panel that activates it would be beneficial to voice users.
Assuming these buttons have unique names I could simply say "click activate panel 2" (where "activate panel 2" is the button name) and switch immediately.
Do you need to manage focus?
Bear in mind that when you switch panels you will by default start at the top each time.
This may be exactly what you want but more than likely this would be a terrible user experience.
Instead you may want to remember the previous focus location. Then if I use the keyboard shortcut it would jump back to the same location in the panel. If I use the voice / button click to change location same again.
However if someone uses headings to navigate this obviously wouldn't work. You could then give them a button directly after the heading that says "resume from previous location" to fix this and use that to manage focus.
User settings
As you can see there are loads of things that different people with different requirements may or may not need.
As such adding all of the features by default would probably make the application worse to use for majority of users.
Instead have a settings screen that lets a user turn on features that benefit them, set their own shortcut keys, turn on or off sticky keys, decide if they want you to manage focus for them (or not) etc.
This is a difficult problem! I have been giving a similar issue a lot of thought. I have outlined one idea that uses ARIA live regions, and an alternative idea that might work better if quick-jump keyboard support is vital.
Live region announcements as part of a <form>
The <output> tag may be what you're looking for. It is mapped to the ARIA role of status so any changes to its content will be announced without any focus change. That way, the user can continue to navigate and make changes on the left side without always having to flip over to the right side to know what changes were made.
The role status has an implicit aria-live value of "polite", so that the announcement will wait until any other descriptive announcement is finished.
It has an implicit aria-atomic value of "true", which means that any change will trigger the announcement of the entire contents of the element -- which may or may not be appropriate for the content. If not, add aria-atomic="false" to read out only the changed node.
If the content inside the <output> could be anything other than phrasing content (including <div>s or heading tags) then you should use a <div> with the role attribute of "status" instead.
Custom keyboard controls can get tricky with various types of assistive technology (AT) software/hardware. Plus those commands probably can't be made easily discoverable. Some ATs provide a keyboard command to flip between a controlling element and the element assigned via its aria-controls attribute. Unfortunately, this functionality is poorly supported, but it is the current standard, so support may get better over time. Currently only NVDA on Windows supports it, with the keyboard command Insert + Alt + M.
Adding aria-controls to an element controlling an <output>/status is mandatory anyway, so give it a unique id attribute and set that as the value of aria-controls on each form element inside the <form>.
If the <output>/status is wrapped in a <fieldset> and the inputs are all wrapped in a containing <fieldset>, then each <fieldset> acts as a grouping container, so the user can navigate between them quickly. As part of this, ensure the <fieldset> containing the <output> directly follows <fieldset> containing the form elements in the source order. If this isn't possible, add the aria-owns attribute to the containing <form> and reference the id attributes of both <fieldset>s with a space in between.
Always-open non-modal <dialog>
You may instead consider making the right side pane an always-open non-modal <dialog>. A <button> next to each interactive element on the left pane would move focus to the <dialog>, and the Escape key would return focus back to the <button>. Focus isn't trapped within a non-modal <dialog>, so the user can still move between each pane using normal navigation methods. The <dialog> needs to have an open attribute to appear and it also needs to have aria-modal="false".
Each <button> would need an aria-controls value referencing the <dialog>'s id attribute, and an aria-haspopup value of "dialog". The <button>s could be invisible until focused.
There's only a single focused point at any given time. So there isn't any real miracle solution, screen reader and other keyboard-only users will necessarily have to repeatedly go back and forth.
IN fact, the most important isn't to be able to switch quickly between the different parts (you must only somehow give a way to do it only with keyboard), but to not lose cursor position when you switch.
For example if I edit something on the left, go to the right to check the result, and then go back to the left side, I expect to find the insertion point exactly where I left it off.
You really have to make sure that this is always correct, and as closest as possible when changes occurs (especially when it's asynchronous, i.e. a change occurs on the right side when you are on the left side).
The most similar accessibility recipe or component is probably split view.
In windows world, the most used shortcuts for cycling between the different splitte parts is F6, and Shift+F6 to cycle in reverse direction.
Don't hesitate to add other easier or additional shortcuts if the switch has to be really frequent, such as Ctrl+Tab, if such shortcuts aren't already used for something else.
F6 and Shift+F6 aren't the easiest shortcuts to perform, especially on laptops where all F1-12 keys may not be available at all or only by using an additional FN key. I personally always found F6 a questionnable choice, but that's only an opinion; at least we have something and that's of course better than nothing.
However, don't replace an existing shortcut commonly used. (for example Ctrl+Tab = switch between different tabs, don't use it for cycling between views if there are tabs in your application and keep it for the tabs)
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 have created a print button in my application that opens a new window that goes to print device layout by appending the current url with QueryString of Print device(?p=1 in my case) and onload it calls window.print() function. But this is useless because all the data user has entered will be lost when it opens a new window containing print device layout of the current page.
I can't think of a way by which I can use the print device layout and pre-populate the page with data user has entered. Can anyone help me with this?
Thanks in advance.
The point of the Print Device to be able to have a different set of Presentation components for display or print. Sometimes it is sufficient (and easier) to just use a print stylesheet, which hides/restyles certain elements: https://stackoverflow.com/a/12773239/19112
Obviously Devices works fine for non-form pages, or forms that have been posted and a confirmation page is shown (no input boxes, just text).
An alternative would be to use Rendering Parameters to set on each control, which could add a .print or .do-not-print class to then be used by the print stylesheet. You would then have to set the appropriate styles in the stylesheet to hide those elements. Note however that you cannot style the iframe content from the parent, you must link a separate stylesheet to the iframe src page if you want to style when printing.
You can append the user inputs to the print URL query string using javascript, for example:
var url = 'Current-Page-URL' + '?p=1' + '&input1=[INPUT1]'+ '&input2=[INPUT2]' etc..
Then in Page load event, you can set these inputs in the corresponding text/dropdown elements
Like mentioned above that device is a different set of presentation that can be used for many purpose. Early years when there weren’t responsive design, I used device to rendering different mobile device. You can use device to render rss feed or anything you want where you want to have different render set.
Another example if you have multi sites and want to rendering them differently you can use device as well.
Sitecore is very flexible that’s why I love it so much. There are always other ways to get same or similar results. From your context I don’t know what you are trying to achieve. If I want to have different set of presentation
here is some approach I will look into, Lavage rendering rules, tap into request pipeline, swap rendering controls in code, on item level specify style sheet…
If you can tell us what you are trying to achieve, I am sure someone will provide you their own solution. Then you will have more options to choose from and get the best fit to your project.
Hope this help.
I'd like to show faces (data-show-faces="true") on my FB like button, but I'm using it in a panel that is very wide but where I can't afford to use a lot of vertical space. I would like to display the faces in the same row as the button, not in a new line.
Is there a way of either configuring the control to do this, or a safe way to do it in css?
As far as I know, there's no good way to do this. Facebook controls the iframe that gets rendered when you use fb:like and they don't make the users who like that object available to you for privacy reasons (those faces are personalized for the user who's viewing them).