Design an accessible Website using CSS

Designing the web page layout is an essential step in the website development. It affects almost every aspect of the website development, from styles, content types, photos, search engine optimization SEO, and definitely the website user friendliness.

There were a deep misunderstanding to the Web as a capable media for content publishing and a potent marketing tool, the graphics designer were using the Internet shamelessly as a mere brochure. I mean they were designing a brochure (a real one) and convert it to a web page using one of the web graphics application like Fireworks, or Dreamweaver. The conversion was usually done using image maps and slicing. Graphics slicing were obscenely abused, I saw many crimes where developer create or import a brochure into Photoshop and start slicing the image into small chunks of gif images, and export the whole design as an HTML. At best they export part of the design from Photoshop and integrate the dynamic parts into the body area of the layout.

Leaving Photoshop and brothers to do the HTML is not a good idea. Really. It is like translating an English site to Arabic language using a machine translator. The end product is gibberish. The sliced layout with mixed Html and images, is harmful for many reasons I will try to highlight them in this post.

HTML is not a presentation layer. Using HTML to design the layout is not the job of HTML. HTML is an XML format to define the data structue of the web page document. I like to describe a document in terms of paragraphs, menu list, sidebar, blockquotes, ordered list, unordered list, those elements are unsurprisingly the elements of HTML. But how you want to render or represent the menu lists, the sidebar, the blockquote, representing those elements is entirely the job of CSS (Cascading Style Sheet) and not the HTML.

What made me a true believer of CSS layout, CSS styling and using HTML only in representing the document in its basic elements is that our eyes are not the only consumer of the web page we develop, there are others, like; search engines crawlers, blinds, mobile web browsers, printers..etc all those consumers will not see or use our graphics as we intended for it to be seen

Search engines will not understand that my website is concerned about farming and agriculture if I did export the titles of the agriculture sections as images from Photoshop. So People searching Google will not find your site only because Google didn't find thesearch keywords in your site. The same goes for blinds. There are using the Internet in a daily basis in Egypt, Arab countries and around the world. For blinds they use Text to speech software to convert "text" to speech, it will simply ignore images, so blinds will miss your website sections menu if it was made of a bunch of images racked into an HTML Table.

Another reason for using CSS is that blinds are needlessly forced to listen to a lot of repeatable content on the top of each of our pages, for no reason but that HTML is rendering first things first, so if we want to put the site menu, contact us, about us, login, and sidebars on top of the page, you could render it on top if you want to, but there is no need to fill the blind with boredom in order for him / her to reach the body of your page content, and force him / her to read through all those content again and again in each of your website pages. We can always use CSS to render different page elements in any position regalrdless of its order as an element in the HTML document.

To summarize the characteristics of a good Website design I can say;

• No style graphics are embeded in HTML, all design and decoration images located in a separated CSS file. No menu list, titles, or any content is represented only by graphics, it should be a text first and then styled and decorated with any graphics the designer decide.
• No Tables are used to define layout columns, Tables are only for tabled data, and not for layout.
• Web page content comes first in the order of HTML document. The title and body of the article of the web page is the first thing you see if you open the source code of the page or see the page without CSS styles, that's good, cause that's how other blinds, search engines, mobile browser will see your page.

I am yet to see CSS developers in Egypt, job posts for CSS developer in Egypt are none. Employers do not know what they are missing, they bet on graphic designers to do the job, and usually graphic designer have no idea what CSS is all about, they will use CSS for styling at best, and not for layout. That's why I will do a small contribution and start a mini series of CSS lessons (hopefully in Arabic too), in order to implement the mentioned principles in designing a good website design.

Git the Version Control System - part one

Git is a Version Control System, it is used to keep a history of all the changes you made into your code, manage releases, makes it easier for more than one programmer to share his/her code with the rest of the group.

There are tens of good VCS out there, the most famous was CVS Concurrent Version System, then came Subversion from the same team of CVS with the same concepts but cleaner than its ancestor. Both CVS and Subversion was free. There are other sophisticated VCS out there some of them are free and the other are proprietary. Linux was developed using a free license version of Mercurial which is pretty good CVS but for more some reason Linus Torvalds was challenged enough to start writing his own VCS, and Git was born.

There are two types of VCS, Central and Distributed. In central VCS like CVS and Subversion, there is always one central repository, you checkout a copy of whatever version you like from the repository, start working on it and then submit your changes into the central repository again.

The Distributed type like Git, there is one or more central repository, and you clone the repository into your local machine, and then you will have a standalone repository. Which is more like forking the development of the code at certain point in its development line into another repository. You then maintain your repository and change to your heart content, and it is up to you or the original (upstream) repository maintainer to merge your changes.

I will write a note on the basic operation of managing my code in GIT. For the sake of simplicity I will not write in this post about how to serve or access remote GIT repository using SSH, I will just assume that all repositories are on local machine.

$ mkdir myapp
$ cd myapp
$ git init
Initialized empty Git repository in .git/

I created a folder for my application, and inside the folder I make Git initialize a new repository.

At this point we should have a folder named .git inside the 'myapp' and that .git folder by itself is a repository, in this folder GIT will store all the transaction, changes, version, releases of your code. The beauty of GIT is that it does not pollute your code folder with other files like Subversion does. Subversion was creating an .svn folder inside each folder in my app folder.

As I said .git is the repository and the rest of your folder is now then called the working copy. the working copy is an important concept. It is your current version files, in Git if you switch to another version of your code, all the files in the folder will be changed to reflect the real version you switched to. We can create a repository without a working copy and that's what we do in case we need to make a central repository where programmer are pulling and pushing changes into it, in that case we do not need a working copy with the repository, this is called a 'bare' repository.

The .git repository folder is now empty, it has no files (or changes) in it. To start populating the repository we use the 'add' Git command. but we actually do not have any files yet, so let's make some files.

$ echo "hello" > dialog.txt

I created a file 'dialog.txt'. Now i will ask Git about the status, and it will answer me with the following information, which match files in three cases:

• The modified files in my working copy that needs to be committed.
• The modified files that are marked for committing.
• The files that are not yet tracked by Git, and they need to be added first to the repository.

Now that we only have one file in the third case.

$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# dialog.txt

Git suggest to use the add command to start tracking the file. What tracking means? Ok, in a working copy there is either tracked files that you want to keep track of, and untracked files which are either newly created and needs to be added to the repository or non source code files like log files, object and comoiled files and in this case we need to tell Git to ignore them and not notifying me about them when we use the 'status' command.

To be more specific the 'add' command does not add the files to the repository here or even convert the untracked files into tracked ones, the 'add' command is actually preparing the files to be committed or added to the repository in the next time you use the commit command. Actually 'add' is adding the files, tracked or not, to an area which is called the 'index', and after you add all the files you need and you feel satisfied that your all the changes you need to commit is in the stage, then you can use the commit command to commit your changes into the repository.

$ git add dialog.txt

Now that we added the dialog.txt it is now in the 'index' and will be commited by the next commit command.

$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached ..." to unstage)
#
# new file: dialog.txt
#

Well, it is time of our first commit. Git is storing the name and email of the committer with each commit, so we need to identify ourselves first to Git.

git config --global user.email "ibrahim@mymail.com"
git config --global user.name "Ibrahim Ahmed"
$ git commit -m "saying hello"

I committed the dialog.txt and notice the '-m', commit always needs a log message, try to write a message describing the changes you've done to the file.

$ echo "what's your name" >> dialog.txt
$ git status

I added one more line to dialog.txt, and git status to see the changes, and Git should giving me that dialog.txt is modified and will be committed in the next comit.

One more time, and excuse my boring repetition, you will need to add first the dialog.txt to the index area, before it is ready to be commit.

$ git add dialog.txt
$ git commit -m "asking about your name"

Ignoring files
Git status will always nag about untracked files, so we should either 'add' it or ignore it.

There are always some files in your app that you do not need to track, files like logs for example.

$ touch myapp.log
$ git status
# On branch master
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# myapp.log
$ echo "*.log" >> .git/info/exclude
$ git status
# On branch master
nothing to commit (working directory clean)

Notice how git status listed myapp.log in untracked files, and when we add a line containing '*.log' to '.git/info/exclude', git status ignored the myapp.log file and gives the message 'working directory clean'

Remove files
'git rm' removes files from the working directory and from the repository. But it also used to remove files from the 'index' using the following;

$ touch delete.me
$ git add delete.me
$ git commit -m "adding delete.me"
$ git rm delete.me
$ echo "how old are you?" >> dialog.txt
$ git add dialog.txt
$ git rm --cached dialog.txt

That's it for the first part of my note about Git, on the second note I will write about diff, clone, pull, adding remote repository, merge, and conflict resolution.

Login to Secure Shell Using Key Authentication

Secure Shell (SSH) is the industry standard encryption protocal for accessing remote server and executing commands in standard shell but in a secure way. SSH is doing a better job protecting the login account from sniffers, way better than its ancestor 'Telnet' which was transfering login account username and password in clear text for all to see. In fact SSH is not only protecting login account by encryption but it is actually encrypting the whole session so that even if sniffers spy on your session they will not be able to decrypt it.

SSH login account is not the only way of authentication, there is SSH Keys authentication. Having an SSH server configured to accept key only authentication is better than server accepting passwords for authentication cause the later is vulnerable to dictionary attacks. So the most secure way to access a remote server is by using key authentication SSH. And that's what I am going to write a note about now.

First we need to make sure that our local system having ssh installed.

$ sudo apt-get install openssh-client

and make sure than ssh server is installed on the server

sudo apt-get install openssh-server
sudo /etc/init.d/sshd start

SSH Key generation
We need to generate a pair of keys, on public for the server to encrypt the data and a private key, which is the only key that could decipher the encrypted data, and this private key is by definition should be kept private. There is many secure algorithm for encryption with different degree of encryption strength. There is DSA and RSA, as far as I know DSA is the standard encryption for the USA government, DSA keys has a 1024 size limit, whereas RSA is unlimited .I chose to use RSA key with a 2048 length, here are the steps.

$ ssh-keygen -v -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ibrahim/.ssh/id_rsa): /home/ibrahim/.ssh/ibrahim_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/ibrahim/.ssh/ibrahim_rsa.
Your public key has been saved in /home/ibrahim/.ssh/ibrahim_rsa.pub.
The key fingerprint is:
66:d2:cc:7b:6a:62:f9:f5:c6:ef:69:fc:7b:87:0d:46 ibrahim@ibrahim
$ chmod 600 /home/ibrahim/.ssh/ibrahim_rsa
$ scp /home/ibrahim/.ssh/ibrahim_dsa.pub ibrahim@myremote.server.com:/home/ibrahim/.ssh

The latest scp command is named secure copy, which is a part of the ssh package, it is a secure remote copy command.

on remote server we should do the following.

$ cat /home/ibrahim/.ssh/ibrahim_rsa.pub > /home/ibrahim/.ssh/authorized_keys

You will be asked for the login password on remote before the copying commences. The file will be copied to login user home directory on remote (/home/ibrahim in that case).

Now, let's login to remote server using the password to configure the sshd server to disable password login and enable keys.

PermitRootLogin no
#Disable Login password
#PasswordAuthentication no
ChallengeResponseAuthentication no
#Allow forwarding yes
AllowTcpForwarding no

• Uncomment 'PasswordAuthentication no' line only after making sure that the key authentication is working properly.
• Disabling root login is recommended anyway, though not useful after disabling login password.
• Allow forwarding is not recommended for multi user hosting envirnoment where keys could be exposed. Anyway, we should only allow it if we intend to forward keys from server to server but keep all our keys on the local machine, which is what I exactly want to do.

Now, let's try login using the keys.

$ ssh -i /home/ibrahim/.ssh/ibrahim_rsa ibrahim@myremote.server.com

you should be asked to approve connecting to the new server, and whither you trust it, answer yes, that's because we are connecting to the remote server to the first time.

Hopefully you should now have access to the remote server shell. Now, edit the sshd config file and disable login by password by uncommenting 'PasswordAuthentication no'.

It is recommended to protect the keys with a passphrase. it is straightforward to do so. In fact you will be asked to provide a passphrase to your private key during key generation and you can skip it if you want. In case you did skip it you can lock it again with a passphrase using the following.

$ ssh-keygen -p

Then it will prompt to put the key file path and you should enter then the password which must be more than 5 chrs.

Of course using keys is not only useful for security reasons, but also for not asking for password every time you use ssh. But thanks to ssh-agent we could save ourselves a few keystrokes, and more importantly use ssh in automated scripts without interrupting the script to prompt for passwords.

SSH Agent

$ eval `ssh-agent`
$ ssh-add /home/ibrahim/.ssh/ibrahim_rsa
$ ssh root@myremote.server.com

We first ran the ssh agent, which is actually a service. then use ssh-add to add the key, them ssh the remote server with only the user name and the remote server address, without providing the key, and if you have protected the key with passphrase you will be asked for the passphrase when you add it. The ssh-agent help in opening a session so we can use ssh to access remote server without giving any keys or password.