The KA_LEN_DIAR weekly planners have been manufactured in the Czech Republic for the last nine years. This year marks the third English edition. They are hand made from recycled paper and each piece is unique.
Graftene is a digital agency based in Bournemouth, England with a mission to help businesses reach new heights.
Volley is a library for Android that manages network requests. It bundles the most important features you’ll need such as accessing JSON APIs, loading images and String requests in an easier-to-use package.
Designed for RPC (Remote Procedure Call) network operations, Volley is perfect for populating UI elements. It’s not for streaming operations like downloading a video or a MP3.
Continue reading %Volley, a Networking Library for Android%
With more than 400 million users, Instagram is an official social media beast, and now that they offer advertising options, it’s a great way to connect with potential customers.
There’s just one problem: Instagram provides almost ZERO help in launching an ad campaign. It’s like the help section was written by an antisocial hermit who has never interacted with real people. An antisocial hermit who, for some reason, likes Instagram.
The point is, the help section sucks.
Look at this first image:
Continue reading %How to Get Started With Instagram Ads%
Over 24% of the Internet uses WordPress, and many of those folks want a mobile app.
It makes perfect sense to use content from WordPress in the app, so that when the website is updated, the app is updated. For example, if you are an online magazine, you would want any new articles you publish to be available in the app instantly. If you make any changes to the website, you’d also want those changes to apply to the app without any extra work.
Some app builders use a third party content management system where you create your app content. If you have a WordPress website, why not use WordPress as the CMS?
WordPress users are accustomed to using plugins and themes to customize their website, and these don’t always translate well to a mobile app. This presents some unique challenges when a developer is approached by a client who wants to mimic their WordPress website in a mobile app. For example, if a client uses BuddyPress to create a social network on their website, and they want a mobile app with the same experience, how can that be accomplished? What about the same situation with an event or ecommerce plugin?
The technical constraints of a mobile app means that integrating website features such as WordPress plugins is often a difficult task. Luckily, there are some options available to get WordPress into a mobile app that can fit any project. Let’s take a look at three of them.
SitePoint has previously covered the topic of WordPress-powered mobile apps, however, in this article we take a deeper dive into three of the options available, discussing the pros and cons of each; App Builders, Custom Hybrid Apps and AppPresser (for which I'm a co-founder).
For each of these methods I will cover building a mobile app with WordPress using hybrid app technology, along with PhoneGap (Narayan Prusty has also covered WordPress and PhoneGap here).
App builders allow you to create a mobile app with no coding, and very little technical expertise.
They can work great if you don’t want to spend a lot of money, and you don’t need anything really custom. There are a variety of app builders, including Mobile Roadie, Shoutem, Good Barber, Reactor, Telerik AppBuilder. Each one has a varying degree of WordPress support, most allow you to integrate posts and comments, but not much else.
For example, Shoutem allows you to pull in posts by installing their plugin on your WordPress site. This lets you display your WordPress content and accept comments to your app.
Continue reading %3 Ways to Create a Mobile App with WordPress%
Back in 2005 when I attended my first (and only) face-to-face WCAG Working Group event in Seattle we couldn’t even comprehend where technology would be today; with the array of smartphones, tablets, laptops and smartwatches to come.
Nevertheless, we were very focused on making the second version of the Web Content Accessibility Guidelines ‘technology neutral’; so that it would still be applicable to any of the myriad of future technologies available now.
In some cases, we were successful, but when it comes to mobile accessibility, unfortunately, we were not.
The W3C has released a discussion paper on Mobile and accessibility and how it relates to WCAG2. It is a good read, but it doesn’t provide any implementation criteria. It does list WCAG2 Techniques that apply to mobile, but there is no information on how they apply to mobile, and there aren’t any additional techniques that are specific only to mobile.
[author_more]
The Unbearable Inaccessibility of Slideshows
8 Steps to Creating Accessible Video
The Final Nail in the Icon Fonts Coffin?
[/author_more]
At AccessibilityOz, we started testing mobile-only sites early last year. Initially, we used the BBC Mobile Accessibility Guidelines and merged them with WCAG2 to conduct our testing.
However, we quickly realised that this wasn’t enough; we found a number of things that were not covered in WCAG2 or the BBC Mobile Accessibility Guidelines and considered many of them quite serious accessibility issues.
This resulted in us developing our own unique AccessibilityOz Mobile Testing Methodology which we have since used in our testing of many mobile-only and responsive websites.
There are a number of ways that viewing a website (whether it is optimized for mobile or not) on a mobile device can be problematic. Here I am going to focus on hover inaccessibility.
Firstly we know that on a mobile device there is no continual access to a keyboard (unless someone is using it as an add-on to the device – or using a Blackberry Classic). WCAG2 requires that all content be accessible to the keyboard interface, but it does not require that all content be accessible to a mouse or to a touchscreen user. The definition of a ‘keyboard interface’ in WCAG2 makes this very clear:
WCAG definition of keyboard interface - interface used by software to obtain keystroke input (link1)
Note 1: A keyboard interface allows users to provide keystroke input to programs even if the native technology does not contain a keyboard.
Example: A touchscreen PDA has a keyboard interface built into its operating system as well as a connector for external keyboards. Applications on the PDA can use the interface to obtain keyboard input either from an external keyboard or from other applications that provide simulated keyboard output, such as handwriting interpreters or speech-to-text applications with "keyboard emulation" functionality.
Note 2: Operation of the application (or parts of the application) through a keyboard-operated mouse emulator, such as MouseKeys2, does not qualify as operation through a keyboard interface because operation of the program is through its pointing device interface, not through its keyboard interface.
That means that a UI component that is accessible to an external keyboard on a mobile device can actually comply with WCAG2; even if it is not accessible via a mouse or via touch. WCAG2 was written this way as back in the 2000s it was incomprehensible that a website would be created that was not mouse-accessible. Keyboard accessibility had to be included in WCAG2 though as it was (and still is) quite common to find keyboard-inaccessible websites. And of course, we didn't even think of touch accessibility.
However, instead of a pointing device, users only have the ability to activate components on the mobile. There is no equivalent ability to ‘hover’ over a component, as you can with the mouse or ‘focus’ on a component, as you can with the keyboard. This can cause a range of functionality problems.
Dropdown or flyout menus are very popular at the moment. In many cases, you hover over the top-most menu item to reveal its sub-menu items.
If that main menu item is actually a link to another page, then this hover feature can’t be replicated on a mobile device. Tapping on the main menu item will just take users to that page; there is no way to replicate the mouse hover effect on a mobile (well some mobile devices have the ability to replicate the hover effect but it certainly isn't a well-known technique). This is one reason that in order to activate the flyout menus on the AccessibilityOz website, you need to actually click on the top-most menu item.
For sites that make this top menu item a link, mobile users have only one option: to activate that top menu item. This means they cannot access the dropdown or flyout menu, as touching the top menu item will activate the link – taking the user to that particular page.
We can see this scenario on LinkedIn.
Continue reading %Mobile Accessibility Fails: Do we need a WCAG3?%
