HTML5 and Browser Caching: Part 3
Part 3: Web Storage
In this final part we cover HTML5 Web Storage which is essentially key/value pairs.
You add data into the store using the key, which is a String, and then retrieve the data by using the same string. The data stored in the value field can be any object supported by Javascript but is actually stored in String format.
Good Bits
- Simple to Use: There’s a variety of ways to access the key/value store, you can use:
localStorage.getItem(“myKey”)
localStorage.setItem(“myKey”, myObj)
functions or use square bracket notation:
var myObj = localStorage[“myKey”]
localStorage[“myKey”] = myObj
This makes it easy to pick up and use for simple tasks.
- Event Support: In order to keep track of changes to the store, you can make use of the storage event. This is fired on the window when ever the setItem(), removeItem(), or clear() functions are called and the result is the store is changed. If these functions don’t change the store no event is fired. This can help with tasks such as logging.
- Browser Support: Web Storage is supported by most widely used desktop and mobile browsers (with the exception of Opera mini/mobile). See the supported list.
Bad Bits
- Storing Strings: When using Web Storage you’re storing strings, not data in its original format. In the case that you want to store a lot of integers or floats, the difference in representation can really add up. Each digit in that integer is being stored as a character, not in the usual representation of an int. This naturally means the same data can take up a lot more space.
- Fixed Size Storage: The standard storage size provided by most browsers is 5MB. Unlike Web SQL Database if you need more space you can’t request more. Instead if you exceed the limit a QUOTA_EXCEEDED_ERR is thrown. Some browsers (including Opera) allow the user to configure the amount of storage space provided within their settings, however this is not something that the developer has any control over so can’t practically be made use of.
HTML5 and Browser Caching: Part 2
Part 2: Web SQL Database
Web SQL Database is essentially a local implementation of SQLLite inside your browser. It can be queried using SQL, and offers a lot more functionality than the simple key-value store that Web Storage provides. There also seems to be a difference in the way browsers handle it.
Good Bits
- Transactions & Queries: Being a database you can setup a schema, and query the data easily. Web SQL also supports transactions, meaning that you can setup tranactions that contain one or more SQL statements. You are then able to rollback the transaction if any of the statements fails (either the SQL or the code in the transaction), so any changes are never committed.
- Variable Size: The default size for the database in most browsers is 5MB. However when you setup the database (and also it seems when extra items are stored) you can request extra space. This usually prompts the user with a dialogue box asking if they want to allow this. This is an advantage over for example using Web Storage as it means that it is often possible to store more than 5MB of data.
Bad Bits
- Browser Support: The API for Web SQL Database is not supported by most desktop browsers (including FireFox and IE) See a useful list. Also they do not plan to introduce support. This is because the specification is no longer being maintained and it looks likely that the IndexedDB standard will take it’s place in future versions, and will be far more widely supported. IndexedDB isn’t currently any supported for this generation of browsers so is not practical to develop for at the moment. For this reason we have chosen to use Web SQL in our mobile application, with a view to replacing this code with the IndexedDB API once this is widely supported.
- Versioning: The implementation of versioning seems a bit odd. You need to know the database version number before you are able to connect to an already existing database, however without being able to connect to a users database you can’t find out what version they are using. This obviously makes things a little difficult when you are trying to upgrade to a newer version, with a different schema.
Using Web SQL Database:
If you are interested in getting your feet wet there’s a great article on how to use Web SQL Database at HTML5 Doctor . It covers creating and connecting to a database, querying and dealing with the results, and also has some nice demos.
HTML5 and Browser Caching: Part 1
HTML5 brings us three flavours of local browser side caching to investigate:
- Application Cache (uses manifest files): http://dev.w3.org/html5/spec/Overview.html#offline
- Web SQL Database: http://dev.w3.org/html5/webdatabase/
- Web Storage: http://dev.w3.org/html5/webstorage/
Part 1: Application Cache
Application Cache uses the manifest file to store a list of resources that you want to cache locally on the users browser.
The cache is updated when the manifest file is changed, independent of whether or not the resources it references have changed. For this reason the manifest file includes a version comment which can be updated to force a refresh.
The includes within the manifest file the ability to fallback to a specified alternative resource should the specified one be unavailable.
Apache Configuration
The apache used will need to be reconfigured to allow the correct mime type to be
returned for manifest files used. For example:
AddType text/cache-manifest .manifest
Would mean that all files that end in .manifest would return the cache-manifest mime type. It also needs a change to prevent the apache itself from caching the manifest file, causing problems when debugging as changes are not picked up.
# Prevent the manifest file from being cached
<Files ~ “^\.*.manifest”>
ExpiresActive On
ExpiresDefault “access”
</Files>
This marks any files ending in .manifest as expired in the apache cached so they are fetched from the server every time. This is important to ensure that when you change the manifest file these changes are picked up by the application so it can make the correct decision about updating the other resources.
Testing
If the manifest file or a resource specified in it fails to download, the entire cache update process fails. The browser will keep using the old application cache in the event of failure.
The HTML file that references the manifest file is automatically cached, so any changes to it will require an update to the manifest file to be picked up.
Useful Resources
Dive into HTML5 – http://diveintohtml5.org/offline.html
Toolbar for Firefox to clear your Application Cache – http://sites.google.com/site/keigoattic/home/webrelated#TOC-Firefox-HTML5-Offline-Cache-and-Loc
Software Engineering Radio
I recently started listening to the Software Engineering Radio podcasts and I think they are well worth a listen. Lots of varied topics so it’s worth sifting though for a topic your interested in, as they have some very interesting interviews. I found quite a lot on Spring, Eclipse and Java development.
When can I use… Support for HTML5, CSS3, etc
For anyone wondering what support the most popular browsers offer for HTML5, CSS3, SVG etc on mobile and desktop versions take a look at:
Show the past current and future compatibility for ie,Firefox, Safari, Chrome, Opera, iOS, Opera Mini, Opera Mobile, Android Browser.
WAI-ARIA accessibility – Notes from converting a web-based mapper.
You can find the WAI-ARIA Spec here: http://www.w3.org/TR/wai-aria/
The first step in making a more accessible version of one of our web mappers, Roam, was to ensure that the site itself was navigable using the keyboard.
Keyboard Support and Managing Focus (from ARIA standard)
- There always needs to be a focus
- All interactive objects should be focusable
- All parts of composite interactive objects should either be focusable or have a documented alternative method to achieve their function, such as a keyboard short cut.
- There should be an obvious, discoverable way, either through tabbing or other standard navigation techniques, for keyboard users to move the focus to any interactive element.
Tabindex used implement managing focus
Can also be used to give elements focus that would not normally be in the tab order (e.g. divs)
For Roam the focus should initially take you to the main content, the map which you can zoom in and out of using the following keyboard inputs:
+ Will zoom the map in
– Will zoom the map out
Arrow keys Will pan the map in the direction of the arrow.
If you hit tab you should get to the Task Menu. This will eventually allow you to expand/collapse the Task Menu but this has not been implemented. Pressing Tab again will take you to the first element in the task menu (Search). From this element you should be able to navigate as follows:
Arrow Keys Switch between the available panels (search, print etc.)
Return / Space Expand or collapse the selected panel
Tab (While panel expanded) moves focus into this panel.
Notes from a yahoo developer adding ARIA support to an accordion widget.
Hitting Tab again will take you through the items on the toolbar above the map (Reset to GB, previous map, next map and print map). These are treated as standard buttons/links. Tab to move between them and return or space will activate the button. The focus will then move to the Hints and Tips section which can be navigated in the same way as the Task Menu. The links on the banner will gain focus (Edina, Home, Contact us) and then finally the terms and conditions link.
ARIA Tags and expected behaviours
It is important to first implement the behaviour that the tag you want to use expected before using this tag on an element.
The tags used in Roam are below:
Role Tags (XHTML) – Landmarks
The role tag is used to define landmarks, to aid in quick navigation.
Below is an image and description of the landmarks specified for Roam (using the Juicy Studio plugin for Firefox to display the landmarks):
main: Main content in a document. Set to the map for Roam.
banner: Site-oriented content typically includes things such as the logo or identity of the site sponsor, and site-specific search tool. A banner usually appears at the top of the page and typically spans the full width. Set to the banner used in Roam.
complementary: A supporting section of the document, designed to be complementary to the main content at a similar level in the DOM hierarchy, but remains meaningful when separated from the main content.
This region was used twice in Roam, for the Task Menu and for the Hints and Tips section. Both of these are complimentary to the main content (the map).
contentinfo: Meta information about the content on the page or the page as a whole. Used for the Terms and conditions bar and copyright text at the base of the page in Roam.
search: A region that contains one or more widgets used to define and execute a search. Used for the place name / grid ref search in Roam.
You can hear the landmarks being announced when using some screen readers. Supported in JAWS 10 only at the moment – use ctl+ insert + semi-colon to list landmarks.
Other Role Tags.
tab / tablist / tabpanel: Used for the side panel Task Menu and Hints and Tips sections. Tablist is used to contain the tabs, and tab panel is used for the expanded content element for each tab.
alert / alertdialog: Used when displaying alerts for searches, generating print map etc. The alert dialog tag is used when focus is required to close the alert. At the moment only used for the search dialog.
button: Used for basic buttons on the toolbar above the map.
navigation: Used for the home link.
tree / treeitem: Used in the legend (map content control) section which displays a legend in tree view. Note that the arrow keys can be used to navigate through the tree items.
ARIA Tags.
aria-expanded: Can be true or false and used in the two side panels (The Task Menu and the Hints and Tips) to show if the currently selected section has been expanded or not.
aria-live: This is used to mark a region as a live region. This means that the content is likely to change without the page being refreshed. Using this tag means that compatible screen readers will read out the changes
that are made as they happen (the ‘rudeness’ of these messages can be configured).
This shows a couple of the live regions in the Roam client. The name of the current view being looked at is marked as this changes when the user zooms in or out. The search results section is also marked as a live region as it gets changed (results added/changed) when a search is made.
Other potential live regions in Roam include the coordinates under the Map Information panel and the my maps listing.
aria-labelledby: This is used on elements whose content can be labelled by text in a different element. The value of this attribute is the id of the element which contains the label text for this element. For example it is used in Roam on the main map content which is labelled by the View name element in the toolbar. It is also used to associate the expandable tabpanels with their tabs (as required in the spec).
aria-describedby: This tag is used to point to an element whose text content describes this element. This is used in Roam to point to an element which describes the map in text format.
Javascript libraries and ARIA
Much of the documentation for ARIA support in the Javascript widget sets is quite sketchy. Roam uses ExtJS which claims to have some support however does not provide any documentation on this. The only support that seems to be implemented is the aria-enabled tree widget which we have used in Roam for the legend (Map Content Control) section.
Some more information can be found here on other javascript libraries and their ARIA support.
Much of the support for the accordion layout used in Roam had to be specifically implemented as the ExtJS accordion widget does not provide any keyboard support as standard.
Accessibility and OpenLayers
In openlayers you can add the KeyboardDefaults control which allows the map to be panned or zoomed using the keyboard controls described above. However this has the problem that it cannot tell if the map is the element which currently has focus, so that a keyboard press, for example using the arrow keys anywhere on the document would pan the map.
This is obviously not what we want as the arrow keys are needed to navigate the menus and select search results, and you don’t want to be panning the map as you look through the available menu tools.
This is considered a bug in the current openlayers and the developers are currently proposing restricting the map responses if the element currently focused is a form element. This does solve the problem of moving through a set of results using the mouse (as this uses a form element) but does not solve the problem of using the keyboard to navigate other widgets. For example the aria standard requires the arrow keys to be used for navigation through trees and menus which may not be in form elements. This still results in map panning when it shouldn’t.
To get around this for Roam I have made an adaptation to the KeyboardsDefaults controls which checks to see if the map is currently in focus and only allows keyboard controlled panning and zooming then. This makes the website very much more accessible for keyboard only users.
Testing Accessibility
This seemed to be the hardest part, as you can implement the tags following the standard but not see any difference in behaviour from any of the screen readers as only certain tags are supported by certain screen reader and browser combinations.
Screen Readers Used
JAWS 11 (demo)
NVDA (free – windows only)
Fire Vox (firefox extension)
In order to find out what tags are supported by particular browser and screen reader combinations, and to find out what the expected behaviour is I found the codetalks Set of ARIA Test Cases very useful.
Additional FireFox Extensions
As well as the screen reader extension Fire Vox, I also found it useful to have the following extensions which help visualise and summarise the tags used:
I also used the following more general extensions for web development which help in allowing you to inspect the elements in the page in more detail:
Access Keys
In addition to the ARIA standard, you can also improve the accessibility of the website by adding some access keys. There exist various standards however the following seems most applicable to EDINA.
Access Key UK Government standards
S – Skip navigation
1 – Home page
2 – What’s new
3 – Site map
4 – Search
5 – Frequently Asked Questions (FAQ)
6 – Help
7 – Complaints procedure
8 – Terms and conditions
9 – Feedback form
0 – Access key details
The following elements support the ACCESSKEY attribute: A, AREA, BUTTON, INPUT, LABEL, and LEGEND, and TEXTAREA. Note to use access keys in firefox use shift+alt+accesskey. Note OL Map is in a div, so will not support an access key.
In Roam the Home Page, Search, Help and Terms and Conditions access keys were implemented.
Further Work for Roam
In Roam you can collapse and expand the entire left and right panels to enable you to see more of the map on your screen. This should be possible using the keyboard (Return or Space when title is focused) and should mark all the content within these panels as aria-hidden when it is no longer viewable to the user. It should also mark the panel itself as in a collapsed state using the aria-expanded=false attribute.
aria-hidden: This is used to show that an element is not visible to the user. This should be used in the side panels when they are collapsed or in the case of the Map Content Control section when they are not visible to the user (because the panels for all product legends exist but only one is visible at a time – the one corresponding to the product currently being viewed).
The ‘My Maps’ section is not currently very accessible as the widgets used are not accessible using the keyboard and are not correctly tagged. This is potential future work.
Geo Development 
