Consider there are Create/Modify links in the GUI and clicking those links Opens up a Create/Modify page. Through tabbing, when the focus ring is on Create/Modify link, i pushed enter button. What should be the Default Focus in the Newly opened Create/Modify page ??
Is there any Rules/Standards of 508 compliance for default focus in the New Page or It depends on the particular Information System developed ??
The default focus should be in the beginning of the Create/Modify page. The page contents should be automatically read out by the screen reader. I am not aware of any rules regarding this but this is normally the acceptance criteria that 508 testers specify.
The focus depends on the flow that you have used in your website.
Check the following URL for more info - "http://www.epa.gov/inter508/toolkit/508_compliance_toolkit_web_apps.htm"
It should be as per client requirement. But mostly by default focus should be in first field. And if first field is DDL then it should be second field.
Related
With the recent "upgrade" to Google Forms saving data, prefilled URLs no longer seem to work.
Steps to recreate problem:
create a Google Form
Create a prefilled URL for some of the fields
Open the form on an Android phone
Create a shortcut on the phone's homescreen from the "Save to homescreen" option on the form's menu
Open the form from the shortcut and submit a response
Open the form again from the shortcut -- the form will no longer have prefilled values.
Anyone have a workaround for this? I have a fairly large form that I use to track some tasks with some standard response values. This worked perfectly before the "upgrade" but now is useless saved as a shortcut. I can still use the prefilled URL from an email or another rich text object available on the phone, but needing to open additional documents is frustrating after getting used to the convenience of one click of an icon for years.
I've had the same issue. Not quite as convenient but I've posted the URL of the prefilled link on a Google note so its still one click away with Google note on the home screen.
I had the same issue. The fix that worked for me was to remove the "autosave" option in the forms settings.
Settings -> Presentation -> Disable auto-save for all respondents
In TYPO3 versions before v9, when using the native form, I always disabled the cache of that specific "contact" page (where the form was placed). If I didn't disable the cace, the form wouldn't redirect to my "confirmation" (v6/v7) or "redirect" page (v8), but instead it would simply reload the (filled-out) form (on the same page).
So, to bypass this and to make sure that the form actually got submitted and forwarded to the correct confirmation page, I always disabled the cache (Page Properties -> Page -> Behaviour -> Disable cache).
In TYPO3 v9 however, this option has been removed, and adding config.no_cache = 1 into that specific page (in a TS template), doesn't seem to do the (same) trick.
I would expect that the form, after clicking the submit button, would forward to the confirmation (redirect) page which I configured insde the form itself. That confirmation page isn't usergroup-protected or anything, it's simply a sub-page of the "contact" page (containing the form) itself.
The actual issue in this case is that you are most likely using some kind of autofill for your fields, e.g. from Chrome or using a form filler extension.
This will also fill the honeypot field of your form which then prevents submitting the form.
Right now there is nothing you can do about this except voting for the bug in the Chromium issue tracker.
As Mathias Brodola righfully points out, this seems to be a problem in Chrome only. I found this following plugin - that completely disables autocomplete support for a form - to be helpful in this matter. It solved my issue (however, it does completely disable auto-complete support for the form):
https://github.com/terrylinooo/jquery.disableAutoFill
AEM/CQ5 (5.6.1) appears to have a deficiency in how content validation works in the out-of-the-box product.
Though component dialogs have a mechanism for validation, the validators only get executed when the dialog is open. The problem is that a component can be added to a page, and without opening the component's dialog, the page can be activated with the unconfigured component. Even worse, it's possible to activate a page without completing mandatory configuration in its page properties dialog.
I have previously dealt with the latter by creating a replication preprocessor (com.day.cq.replication.Preprocessor) which validated the expected page properties. This is suboptimal, since it has its own validation logic, which may diverge from the dialog validators. It also does nothing to validate components on the page.
Is there any way to leverage the validation rules in component dialogs for validating content prior to activation? If not, do you have any other suggestions for improving pre-activation content (page and component properties) validation?
One option can be to define a flag in component dialog which you can use to show visible notification text to configure the component and update it once it is configured.
It actually is more of a knowledge problem than a product issue.
Aem can be configured for non-technical authors who can add/modify content on author instance and then can submit it for Review via workflow.
The reviewer can then verify and replicate content if found to be fine.
I am using TYPO3 4.5.23, when i login /typo3 admin site, over one page, it shows The BE-USER Tom began to edit content on this page 4 min ago, So my question is: is there a way that I can see what Tom edit on this page?
You see this message per record base. So if you get this message, you usually should see it on the page-record, or on some tt_content elements etc. In list-view the icon is shown on each record which has been edited.
If you edit an record, there will be a notice.
This message disappears after two hours. If an user log out, the message is not removed (missing feature;)! But if an editor close (or save & close) an record, this message will disapear. Teach your editors to close records.
If you want to see exactly what Tom edited (not just which content element, but which content he changed), use the "History/Undo" tool. Right-click the page in the tree and click "History/Undo". There you see all the changes that have been made in a diff-like view and also the user that made the change.
If you would like to see a system-wide log for all changes that have been made by this user, just log in as admin and click on "Admin Tools" and then on "Log" in the menu on the left. Then you will get a dropdown-box for all users in your Typo3-backend and you can choose the desired user and see all the changes that he has ever made.
Google's AdWords policies state:
Pop-Ups
Don't use pop-up windows on your site.
We do not approve destination URLs that generate pop-ups when users enter
or leave your landing page.
We consider a pop-up to be any window, regardless of content, that opens
in addition to the original window.
This includes pop-unders, timed or intermittent pop-ups, mock system
warnings, and pages that automatically initiate a download.
Does anyone know if that includes Lightbox effect popups that occur within the same browser window, and just lay on top of the content? The terms "popup" and "window" are ambiguous in the above policy, and it's not clear whether by "window" they mean simply the browser window, or whether the Lightbox content would count as a new window.
Anyone know for sure?
As long as the lightbox opens only on user's direct action of, supposedly, clicking a thumbnail to open a bigger version, I don't think it's treated as a popup per se.
Opening a pop-up/pop-under on page open or leave, or through clickjacking is evil and those are the cases condemned by the policy.
Here's a blog post from Adwords team about why popups are disapproved. You can see that lightbox does not fit the profile.