Moved wordpress installation to new host (Rochen). I got message unable to establish connection to the database.
I tried changing the wp-config.php file DB_HOST from what it was previously:
/** MySQL hostname */
/** MySQL hostname */
Then I got this message, which seems to be an improvement. At least there seems to be a connection to the database.
Warning: require_once(/home/bauh/public_html/wp-content/plugins/nextgen-gallery/widgets/widgets.php) [function.require-once]: failed to open stream: No such file or directory in /home/bauh/public_html/wp-content/plugins/nextgen-gallery/nggallery.php on line 285
Fatal error: require_once() [function.require]: Failed opening required ‘/home/bauh/public_html/wp-content/plugins/nextgen-gallery/widgets/widgets.php’ (include_path=’.:/usr/lib/php:/usr/local/lib/php’) in /home/bauh/public_html/wp-content/plugins/nextgen-gallery/nggallery.php on line 285
Indeed, we do not have to register/purchase a temporary URL. …
Article ID: 3 Created on: 21/09/2008 12:00 am Modified on: 13/10/2010 02:20 am
Many customers find it useful to be able to access their account before changing the name servers for their domain name. You can access any account on our servers before the DNS propagates using the following details.
Important: You should replace “servername” with the name of the server hosting your website. E.g. findlay.directrouter.com. You should replace “username” with the cPanel username of your account e.g. /~jsmith.
Temporary HTTP (Website) Access:
Temporary cPanel Access:
Login with the account’s cPanel username and password.
Temporary FTP Access:
Use the following as FTP address: servername.directrouter.com
Login with account’s cPanel username and password.
You servername will be stated in your Rochen Welcome Email.
UK-based Rochen Accounts:
Use “directrouter.co.uk” instead of “directrouter.com”.
I’m getting moving on my capstone, and I think it might be handy to keep a blog on the process.
For starters, I have to move Sarah’s site (WordPress) to a new host. She needs to get away from the current host and the guy who maintains her site. I have the files needed to upload to the new server. I’m going to use them to get the site up and running but not live. We will point her domain name to the new host later this month between Christmas and New Year. Or after New Year.
I got Sarah’s email from Rochenhost.com. I don’t think that the DNS has pointed her testbauhanpublishing.com domain name to the server yet. I recall some similar wait-and-see going on when I created the new site for innerphoenixtest.com. The email came Monday at noon, and today is Wednesday. The email says in part “NOTE: Your domains will resolve to your Rochen account 48 – 72 hours”. So I’ll try again tomorrow and see if it works.
I am posting an index.html file to the public_html folder. I am able to use ftp but only with the temporary marbella.directrouter.com URL.
I’d like to get moving with this and hope I don’t get bogged down with user error.
You are tasked with developing an educational Web site that includes podcasts, video, and Flash presentations while complying with Section 508. (http://www.access-board.gov/508.htm). Think “details” because government funding of this Web site is at stake. What follows is a rough checklist of considerations when incorporating multimedia into your site.
The biggest challenges in building such a site come in meeting the needs of all potential users.
Keep in mind: users might include individuals who have special needs in the following broad categories:
- physical/motor limitations
In some cases, multimedia may provide a good solution to some users while closing a door on other users. While a podcast may be highly accessible content for a user with poor vision, a hearing-impaired user loses access. The interactive Flash presentation may contain text equivalents to its audio, but a user with limited motor ability may not be able to use a mouse to click on buttons in the changing display. Alternatives must be incorporated into the multimedia or alongside it so that all users may benefit from the content.
A Rough Checklist of Media and Their Additional Requirements for Accessibility
Audio (podcasts, mp3 files, etc.)
- Include a good description of the content
- Include additional HTML pages with text transcripts or a separate text file link
Video (vodcasts, YouTube embeds, etc.)
- As with audio, provide text transcripts
- Consider all audio elements including text, background sounds/music that might be relevant to the message of the video
- As with other accessibility issues, consider carefully what the user needs from the content, and be sure to provide it in alternative formats that are accessible
- Descriptions of action that is relevant to the message of the video must be provided
- Allow user control of playback; therefore, do not incorporate autoplay
- Provide both audio and text descriptions for the video (Visual information necessary to understand the content may not be natively present in the audio track)
- The same considerations for audio and video apply
- Equivalent alternatives for multimedia must be synchronized with the presentation
- For any video content, use captioning — either open or closed
- Closed captioning: user controls whether it is on or off; it exists as a separate data stream from the time-based content and may be archived an searchable in a way that audio is not
- Open captioning: captions are part of the time-based stream (i.e. video-rendered text) and as such are not text-searchable and are subject to loss of quality (eg. during compression or resampling of resolution)
- Visual information necessary to understand the content must be described in an audio file that is synchronized with the video
- Be aware of flickering that might occur in the video of a frequency between 2Hz and 55Hz, as they trigger some seizure disorders, and can distract users with some cognitive disabilities (this applies to all other Web elements as well); any media that must be posted containing such content must be preceded with a warning and must be controllable (again, no autostart) by the user
- Make the Flash content natively accessible to the screen reader user whenever possible
- Make the Flash content self-voicing with on/off control
Provide non-Flash alternatives to the content whenever possible; this content can utilize any of a variety of techniques that are accessible and may indeed need to make use of a variety of media in order to claim adequacy as an alternative to the Flash content
- Make up for areas of Flash content that fail to meet Section 508 standards; although Flash has the potential to provide highly accessible content, it is rarely designed to meet all accessibility standards at the same time
- When Flash content contains audio or video, apply the same considerations as mentioned in the sections above on audio and video content
Resources and References
- Section 508 Guide
- HowTo .gov: a Resource for Agencies
- WebAIM Flash Techniques
- YouTube Closed Captioning explained/illustrated
- Open vs. Closed Captioning
- User testing – nothing beats the perspective of users who need the different kinds of accessibility your site should provide
- Your head …
Remember that making content accessible to all users requires that you think about content in a holistic way: What is its context? What is the message the content conveys? What parts of the content are accessible or not accessible? … and to whom? Asking these questions early and often will help you meet the needs of the broadest possible audience.
What follows is a rough outline for conducting an accessibility audit for a client.
Strategy and scope
Clarify the goals of the organization requesting the audit.
- Why are they doing the audit?
- What level of accessibility do they want to achieve?
- What level of accessibility is required for them to achieve if any?
- Do they have an accessibility policy? Will developing such a policy be part of the evaluation?
- How much of the site needs to be tested.
Based on the clarifications from the above points, make some recommendations and act on the following tasks.
- Incorporate live users
- Use automated accessibility testing
- Select portions of the site to test and be sure to include:
- Most frequently-used pages
- A variety of pages
- Pages with forms and tables
- Pages generated by the CMS in response to user input
- Information graphics
- Pages with scripts or programs
- Make a list of accessibility checkpoints (based on standards) and create strategies to test for them.
- Make sure the upper management is involved and discuss the importance of involving and educating the staff, especially those who will be responsible for creating and posting content.
Discuss how the findings will be used (fix the site or re-do the site is one possible consideration)
- Provide a report and prioritized, actionable steps for improving the site to the desired level of accessibility
- Include building accessibility into processes for managing the site
- Recommend follow-up audits/schedules
- Consider bigger issues such as whether to fix or to re-do
Entering some text in the alt attribute (not alt tag, as it is commonly referred to) always made me feel a little better about the site I was building. There would always be, however, that apprehensive feeling of wondering just what I should be entering as alt text.
That nagging feeling would intensify as I realized I was being inconsistent in the kind of text I was using. “An image of …” I would sometimes say. Or sometimes I would just repeat the caption already stated elsewhere in the surrounding text. Both were ill-conceived ideas.
That nagging feeling really came from not knowing at all what kind of alt tag would be useful to someone using a screen reader. Every time I tried to imagine it, I would come up with something a little different. Thus the inconsistency. Thus the clumsiness.
Now I have a framework for thinking about images and using the alt tag in context. It will take practice. My main takeaway is that use of the alt attribute depends on whether the image is:
Those are Zoe Gillenwater’s points. In WebAIM’s article on alternative text , they frame it in terms of developers needing to present the Content and Function of the images within our Web content. Alternative text needs to accompany every non-decorative image. Alternative text, however can refer to either an alt attribute within an img tag or to information within the body of text adjacent to the image or on the page with that image. In some cases, alternative text can be provided on a separate Web page linked via a longdesc attribute (and sometimes also within an anchor tag).
Every image must have an alt attribute! Even if the image is purely decorative, and in those cases, the alt attribute should be empty (alt=””). When the alt attribute is empty, screen readers will ignore the image. If the alt attribute is not there at all, screen readers will substitute the image file name for alt text, and that can simply be an obstacle for a screen reader user.
As WebAIM states, “Context is everything.” Whether the image is illustrative, part of a link or image map, decorative, or functional. Whether the content of the image is already present in the text surrounding it. The alt attribute needs to consider these contextual possibilities and function accordingly. According to WebAIM, the alternative text should be:
- Accurate and equivalent
- Not redundant
- Not state “image of” as part of its description
Like semantic markup, alternative text can be haphazard. Like semantic markup and like good heading structures and heading text, alternative text must be placed with thoughtful consideration to the other content on the page, especially the content immediately surrounding the image.
This is a consideration I plan to take very seriously as a Web developer. There are challenges, especially where work on existing sites comes into play. And there will always be clients who need to be educated on the topic and “sold” on it when their ideas conflict with accessibility principles. But once the basics are understood, putting them into practice is not difficult. Yes, doing it well will require thought and practice, but Web sites utilizing good accessibility techniques are the ones that fulfill the mission of the “Web for everyone.”
Academics mimic life: building site accessibility in the real world
This is a good topic to be analyzing while on the cusp of building a new set of list-based horizontal and vertical navigation schemes. I made sure to do my research on accessibility before starting the nav menus that are on my deliverables list, and that is turning out to be ideal, because now I can easily build even better accessibility into my deliverables than is required. They will have a much higher value with very little sweat on my part.
The nav menus I initially had in mind would have been structured with semantic list-based HTML, and that’s half the battle right there, but there are other techniques that increase the level of accessibility of menus — and pages — beyond that minimal level. They are techniques that do not affect the look of the page for sighted users, but they definitely enhance the user experience for visually impaired visitors of the site.
Some of the more thoughtful techniques are:
- Using the off-left technique to hide text useful for screen readers, but too cluttered for the visual page — text such as “Main Navigation”
- Making rollovers work for both mouse users and keyboard (tab-key) users
- Skip Navigation Links — elements that allow users to better navigate the linearized Web page that is imposed on many people with vision or motor challenges
Accessibility relies first on good markup
Reading through a list of headings to get a sense of the structure and content of a page is the most basic task of a visually impaired person. Similarly, using a keyboard-only to quickly tab through headings and links is central for someone who can’t use a mouse due to physical limitations. Both of these basic tasks rely on good semantic markup. So even before a developer or designer might need to think of enhancing accessibility, they should nail the basics of page structure. That’s not accessibility best practices, that’s just plain best practices.
Even the content of the page needs to be taken into consideration. The usefulness of descriptive heading text and link text can’t be ignored. Think about these things as they are being written or edited. No one wants to go back and edit the content of archived articles for poorly written headings and links.
Some of the more basic guidelines that affect markup as well as page content are:
- Using semantic heading markup so that a list of only headings makes sense of the page
- Writing heading text that is descriptive of the content following the heading and thus useful for someone who can’t do a quick visual scan of the text
- Writing link text that clearly explains what the link is pointing to — imagine the frustration of reading a link list that consists of 20 links that read “click here”
Having this strategizing experience now, I can more easily explain to reluctant clients why it is better to build accessibility into a site during construction than to retrofit a site after the fact.
The clear argument for cost-effectiveness
Yet nailing the basic page structure often goes overlooked. It goes overlooked because the focus so often is on the visual presentation of the page, which doesn’t necessarily have to be backed by semantic markup. However, all of the presentational workings of the site — the CSS — is based on the markup regardless of whether the markup adheres to standards or to whim.
So, now think about doing an accessibility retrofit of a site with whimsical markup. You must approach the biggest problem first — the semantic markup of the headings and navigation elements. But wait. All of the presentational CSS relies on the way the content is tagged with HTML.
“You mean I have to rethink what content is tagged h1, h2, etc? I have to change those tags? No way. That would completely whack the way the way the headings look. It would make the current presentation look like a jumbled jigsaw puzzle. Things would suddenly be the wrong size, the wrong color. I would have to go into the CSS and practically rewrite it all because the CSS relies on the choices I made in doing the HTML markup. By fixing one problem CSS rule, I would create a new problem in a different rule. It could be never ending.”
Realizing that problem is the clearest reason to put accessibility at the beginning of the project. Doing an accessibility retrofit does not mean adding new features. It means cleaning up code that in the bigger picture could be like replacing a building’s foundation. Better to get the foundation right when it’s easy to work on. Once it has a multi-story building resting on it, a relatively small fix can become a monumental task.
First, some really helpful resources for getting the finer points of Voice Over:
There’s a lot more to VoiceOver than I thought. It seems to be quite controllable, but there are many, many keyboard shortcuts to learn. I downloaded an eval document that helped me narrow down the keystrokes for the following tasks.
When reading the CNN page for headings (control-option-U), the list made sense and I was able to navigate through all the headings in a fairly sensible order. Hitting Return goes to that link and reads it, then control-option-u begins reading the rest of the content under the heading. I wanted to watch the video associated with the h1 in the center column. Once I navigated to the heading, using control-option-right arrow put the focus on “click to play” and I was able to “click”: shift-control-option-spacebar. I’m assuming that’s the normal order that a screen reader user would follow for such a task. Since I could see a “focus” rectangle, I knew which keys to click.
When viewing links (control-option-U, right arrow) it was pretty tedious to get through all the horizontal navigation at the top of the page. The first link, the CNN logo / home link, was non-descriptively named “/1”. The rest had much better descriptions. There are a lot of links on the page to get through.
The images were often read identically to the link text below them, so they were not often descriptive of the image content.
I was able to browse links in a separate list and images in a separate list.
The ESPN page was extremely tedious with all of its links. the scores were pretty cryptic, so you would really need to establish some familiarity with the site to know what was going on. Actively navigating them for a specific sport, such as Tennis, was extremely difficult. I would never be able to do it without seeing the focus rectangle on the screen.
The headings didn’t all make sense to me. I don’t know what the “POY Debate” is so I clicked on it to find out. I could hear the heading, but was unable to “click” using the shift-control-option-spacebar for some reason. Argh. All in all, it was an infuriating page to navigate compared to the CNN page, even when I cheated and looked at the screen.
There was a list of images that I could access, and that worked okay. They were very brief descriptions.
Finding something basketball related was difficult for me because I don’t know basketball. I finally recognized the name Shaq. Yeah, like I said. Not a basketball fan.
All in all, ESPN was an incredibly difficult site to navigate. I’d love to know how long the learning curve is and if it’s worth it.
Thinking about Web accessibility, even as briefly as I have been, opens up a large chapter in my understanding of Web technology and how well or not well it is working for all of us. While many of us comment on what information overload is doing to our lives, there are many people for whom all that information would be incredibly useful if it weren’t for all the kinks in their information fire hose.
The Web Accessibility In Mind (WebAIM.org) survey provides an interesting overview of the issues and some of the difficulty in addressing them. While accessibility standards are outlined with good clarity elsewhere (http://www.w3.org/TR/WCAG20/), things become less clear when examining the preferences of those they benefit. The clarity tends to break down between parts of the audience who are highly-proficient at screen reader use as opposed to less-proficient users, but sometimes, the reasons for diverging opinions were harder to name.
I was unaware until recently that when Using a screen reader that there is sometimes screen-reader specific content available. The WebAIM report notes that this content is widely preferred by screen reader users over accessing the text-only version of a Web site, when that option is also available. The WebAIM report suggests that this is due to the attractiveness of audience-specific content. It makes sense that an audience will appreciate and respond to content that is geared to them and presumably more useful to them. That is, after all, the focus of so much Web marketing. I am very curious to know the particulars of generating screen-reader specific content. One site I have run across that specifically addresses accessibility and includes at least one page describing some its accessibility features is Food Solutions New England.
I make increasing use of Web applications in the cloud. If asked how accessible these applications are, I would have agreed with those survey responders without disabilities in guessing that such applications are not accessible. Twenty-four percent of responders, however, answered that they are somewhat accessible. To me, this is a surprisingly large number. In this group were people with disabilities and Firefox users. The Firefox users had more favorable impressions, probably due to the Accessible Rich Internet Applications (ARIA) support of Firefox, as the report says. So this is encouraging to me, as I would have expected a much worse response to Web 2.0 usability.
I was also surprised by highly-proficient responders’ interest in reading the Alt tags for images that exist on a page for enhancement of the mood or feel of a Web page. Those with disabilities preferred that the image be described, which I think is great. As a designer, my own mental image of a page enhances my experience of it in many ways. Similarly, I think, users who are not able to see a page, can have a richer experience of it when it’s appearance is described, and their own mental image is enhanced. Again, there is a slight preference for this among the more skilled users of screen readers.
At first, I was a big fan of Flash, but I am now becoming more aware of the problems it poses on the Web — in this case, those are accessibility problems. I am much less a fan of Flash now than I have been in the past. It’s ubiquitousness and market-penetration is somewhat alarming, now, whereas it was appealing, before.
I am still fond of the PDF format. (See my earlier blog post.) It seems to have its accessibility issues, but the survey is not so clear on whether the PDF format is good or bad. I wonder if much of the PDF accessibility problems might stem from how the PDF was generated or the structure of the document it was generated from. I hope that the format can be improved upon, because it certainly has excellent applications.
The report notes that “The wide range of user responses makes it difficult to provide definitive recommendations for many things.” Although this may be the case for recommendations, the report still lends a lot of insight to user behavior with screen readers that a newbie graphic designer and Web developer like me can benefit from.
A new client asked me to format an eBook for him to market on Amazon and iTunes. I was pretty excited. Having been a book designer for years, I’ve been watching the rise of the eBook (and the decline of the print book) with alternating feelings of fascination, dread, and excitement. I had done a little research on eBooks, but I hadn’t tried my hand at creating one. This was a great (and paid) opportunity to do so. I discovered some interesting things.
1. It’s not as easy as it should be
Adobe InDesign is the biggest software tool for book publishing out there. It has a clear “Export for EPUB” menu item. That should be all there is to it, right. Build the book, export. Well, okay, I figure all the text has to be in one thread, and the graphics need to be anchored in the text, and keep the layout very basic. That seemed obvious to me. It was only the beginning. Adobe has a video series on the process that was very helpful, but I thought it was silly that the process needs to include two other pieces of software — shareware, no less — in order to tweak the EPUB file and any other eBook format you need to create: Calibre and Springy. It was also silly that I had to search for this stuff and poke through a white paper on the topic. In order to have a decent EPUB file, it seems you need to tweak the CSS after InDesign exports it, so Springy is required to access the CSS file within the EPUB. Further tweaking and the ability to export to different formats such as .mobi for the Amazon Kindle is provided by Calibre. Isn’t the eBook market going nuts right now? Why is Adobe not more on top of this and providing a comprehensive solution?
2. eBook readers seem to be quirky in how they choose to display things
Or maybe the problem is my file. I need to read up on Apple’s iBooks app on their iTunes Connect site. If a graphic does not fit on a page immediately after the preceding text, the iBooks app will start the graphic on one page and finish it on the next. That’s a problem. Stanza, another eBook app does not do that. My client also had a problem where iBooks on the iPad would not display the cover page for the book. So, likely, my file is not up to standards. Or the readers are just doing their own thing. The Kindle file also had issues I was able to resolve with export options found in Calibre. Hopefully I can resolve all of these issues soon. Regardless, my client was satisfied with the results and has more eBooks for me to work on.
It’s exciting to create something in a new media and learn about the process. I’m glad for the opportunity to broaden my book production knowledge, and I can’t help but wonder how exciting it would be to work on an enhanced eBook. The headway Apple made in this area with the iPad is very exciting, with the publication of The Elements being in the vanguard of enhanced eBooks. I realize enhanced eBooks go well beyond the capability of standard formats. The Elements as well as other books like it are stand-alone apps. There’s a lot more learning required to enter that field, I suspect.
3. An EPUB file is a zipped Web site.
The elements enclosed in an EPUB file are JPG files, HTML files, CSS, files, XML files and a few other files specific to the EPUB specification. It really is pretty funny that way — it’s a Web site. It almost seems that the program to be using in the design of eBooks is Dreamweaver rather than InDesign.