Currently in our web application, Trinidad JSF tr:table tag is used to display information in the table format. Upon using the attribute rowSelection=single, radio button displayed automatically for each row in a table and name/text next to this control is not visible to the user.
When user navigates with tab key to select the radio button control or user clicks on the same with mouse button, focus with dotted line is not displayed on the control.
What are the different approaches to display dotted line (provided by IE browser) around the radio button / check box control created by Irinidad JSF table tag?
End user requires this accessibility feature.
Right now, we are using,
myfaces-api-1.1.4.jar, myfaces-impl-1.1.4.jar,
trinidad-api-1.0.7.jar,trinidad-impl-1.0.7.jar,
Browser IE 8.0
Find your CSS file, look for any lines that have
outline: none;
And remove them.
This will fix most, if not all of your missing focus indicator problems. There might be scenarios where you have a hidden overflow that is causing the outline to not show up on some browsers. You would have to find those and fix them by adding appropriate focus styles.
Related
I've been doing searches trying to find help on this, but so far all I have found is how to set options for popping up a SharePoint modal dialog box from custom code.
However, I haven't created any custom web parts to display modal dialogs. What's happening, is if someone clicks the upload document button in a library, the upload document modal dialog comes up, but the ok and cancel buttons are half off of the bottom of the box. Users can click on them, but it just doesn't look very good.
I started playing with the CSS to make the modal dialog box bigger to reveal the buttons, and that works for the most part, but the real problem is the grant user permission dialog box.
When that is clicked, it doesn't show the ok and cancel buttons, and maximizing the dialog box doesn't reveal them. The user has to hit tab about 5-10 times before the focus moves to the ok button and is then clickable.
I would post an image, but I don't have enough reputation to do so.
Has anyone come across this? It seems very strange that the out of the box setting would have this problem.
The CSS that I use to adjust the height and width of the modal dialog is:
.ms-dlgFrame, .ms-dlgContent, .ms-dlgBorder, .ms-dlgFrameContainer
I'm just trying to set the height/min-height values, but I haven't had much luck.
We're using Internet Explorer 11 to view the pages.
Stevangelista actually pointed me in the right direction, I wish I could mark comments as answers, and since I'm new I can't upvote the comment, but here's the solution:
I am using a customized master page, and that comment had me take a look at the elements in the page.
Since the master page is being used in the dialog boxes as well, I used the s4-notdlg class to remove parts that weren't needed in the dialogs. Those parts were pushing the buttons below the bottom of the screen.
I'm not a css expert, so there may be ways of keeping those parts and still have the buttons accessible, but the particular issue I was trying to fix was resolved by using the s4-notdlg class to objects in my custom master page.
I'm sure I am missing something straightforward and simple, but in xpages, using a tabbed panel, who do I get all the tabs to print when the users prints the page?
You can use a Dojo tab container (part of the extension library) instead of the standard tabbed panel. With the Dojo tab container the content of all tabs is loaded at once (in opposite to the standard tabbed panel, as Tim said), so you could do some CSS magic to make all tabs visible when printing.
Tim recommends building a separate XPage for printing, and I second that. Organize the content of the tabs in custom controls, create a new XPage for example with the suffix "_print" and include the custom controls in it without the tabbed panel. Then create a button, link or whatever in the first XPage which simple opens an XPage with the same name plus "_print" in a new window.
In the "_print" Xpage you can use a "window.print" after the page loads to open the print dialog automatically.
This technique has the advantage that you can style the printing exactly as needed. You can even control which content to include when printing by using the visible/rendered property and compute to render controls only when the current page name does not include "_print".
We have are getting a strange behavior with the radio groups in our templates. Each of the radio groups is required, however, when a radio button from a group is selected, the next radio button (not the next group) gets focus. This will confuse our users as they will think they have to click each radio. Moreover, it would be helpful if an entire group could have focus as opposed to individual radios.
Is there a way to give the group focus as opposed to the individual radio?
The manner in which Radio Buttons (or any other type of input element) get focus in the Signing Session UI is not configurable via the API, nor is it configurable via the DocuSign web console.
we can change this option from Docusign settings.
Preferences->Account Administration->Features->signing auto-navigation rule-> Navigate Blank Required Fields
This will move focus to next field when a radio button is selected from Radio group.
I would like to collect your ideas on the following:
SharePoint 2010 (and 2007) does have a preview button... while you are editing a publishing page you can switch to the "Page" tab and hit the Preview button:
Clicking this button does some magic to save your data, and opens a new window where the preview page is displayed. Nice, but could be better. What I would like is live update on editing of field controls from the edit page on the preview page.
My thoughts on this is are as follows:
Field types have an ID. For rendering the field values on your preview page, subclass from the standard FieldValue control, and render a span with the same ID around the field value html. So if we have the text ABC in the content editable div of a RichTextFiled X, render the field value as ABC in the display output (for example using EditModePanels for Display and Edit)
Add key-stroke event handler on all fields for the edit mode page (using for example jQuery), on key press copy contents from edit browser window to preview browser window
Transfer can be done using http://www.sfpeter.com/2008/03/13/communication-between-browser-windows-with-jquery-my-new-plugin/.
Does this sound doable? Would be great to work dual monitor, edit on one monitor, preview page in its real rendering on the other monitor. Especially if the edit mode differs from the display mode.
Looking forward to your input!
I will answer my own question. It is not as easy as its sounds. Fields can use things like reusable content and render patterns. These features render at server side, and change the output. This would require postbacks, which renders the whole thing useless. Lets stay with the already available preview button.
Using LWUIT framework to develop mobile application.
In LWUIT by default first command is placed in the left and subsequent commands will be placed in the right menu of the form including the command which is already placed in form left.I need to add two menus to form.Left menu contains general application specific commands such as "Minimize","Back" and "Exit". Right Menu contains screen specific commands such as "Play Audio","Play Video" etc... Initially left softbutton of the form contains the text "Options" and the right softbutton of the form contains the text "Menu". When user selects "Options", a menu will be displayed with the following commands:
Minimize
Back
Exit
When user selects right soft button "Menu", a menu will be displayed with screen specific commands:
Play Audio
Play Video etc...
Commands of the right menu keeps changing from one form to another form, whereas the commands of left menu remains the same for all screens(forms). I know command menu can be customized by overriding "Form.createCommandList(Vector)" which returns a list. But here in my case I need two lists(menus). One at the left of the form and the other one at the right of the form.Please do help me in resolving this issue.
A LWUIT menu is just a dialog containing a List (or buttons for touch menu or pretty much anything you want), so to implement this just create a Command called options and place it in the left soft button. When options is pressed just show the dialog with your "additional commands". Since a List can accept a command array or vector doing something like this can be really easy.
You can look at the code for MenuBar which is pretty simple, you can also replace the menu bar component in the latest version LWUIT (SVN at the moment) but that seems redundant for this particular use case.