The accessibility of Facebook, Part 2: Account and Profile Settings


Part 1 of our Facebook test focused on the initial registration process. In the second part of our test, we investigate whether customising account and profile settings causes accessibility issues.


This is a translation of the German article covering part 2 of our Facebook accessibility test (part 3 will follow in July). The article provides a summary of the problems identified. Please also refer to part 1: the Facebook registration process.

We were covering the German profile settings, which may differ from other language versions of Facebook. The detailed test report is available only in German.

What have we tested?

Screenshot of Facebook privacy settings

Facebook Privacy settings

After we got successfully registered in part one of our Facebook test, we now look at the various settings to be made on user account and profile pages that are necessary to use the service efficiently and securely. The profile forms are filled out, privacy settings are customised, and email notification settings are revised. This means we have not yet entered the core functionality of Facebook: finding 'friends' and networking. This will be the subject of the third and final test.

Familiar problems identified in the first test

We have already encountered many of the evident problems in the first test. They relate to the general page layout (scalability and contrast), the structuring of content, the problems when using customised settings such as a different colour scheme, and the design and implemenation of general elements that are repeated across pages (menus and navigation elements).

We are not going to repeat the discussion of these problems and focus instead on issues related to the new functions that we have encountered an the profile pages. (Naturally, the resulting score also reflects the known problems discussed in the first test.)

Inconsistent strucuturing

The account and profile settings investigated in the test are implemented with the known HTML form elements. It helps to apply a clear and consistent structure and layout across such forms whereever possible. This facilitates getting an overview of what input is required and helps using all forms in a familiar fashion. Such consistency is absent in the case of Facebook. Each form applies a completely different approach to layout and structuring:

  • In some cases, input elements are positioned in a rather awkward mesh-up of data and layout tables. Elsewhere, form elements are positioned with CSS, in still other cases with layout tables.
  • The use of submit buttons for the submission of form input is not handled uniformly. Some forms, for example, the privacy settings, do away with submit entirely. Many users will wonder where and how they are now going to save the settings they have made.
  • The use of fieldset and legend appears rather haphazard.
  • Some foms completely do away with label, others use them.
  • One form requires WAI-ARIA support to be usable for screen reader users (see above).

That way, each form turns into an exciting new adventure for screenreader users.


In the first part of the test, we noted and appreciated the use of WAI-ARIA for structuring page content through document landmarks that were used consistently on the pages investigated. When looking at the user settings for privacy, another aspect of WAI-ARIA can be seen. Here, it is used to mimic input elements that correspond in shape and behaviour to HTML select menus:

WAI-ARIA select menus on the page for privacy settings (Privatsphäre-Einstellungen)

WAI-ARIA select menus a on the page 'privacy settings' (Privatsphäre-Einstellungen)

Since these input elements do not use appropriate native HTML-elements, older screenreaders and browsers (e.g. Jaws8/IE7) have no chance to 'get' the roles and names of these custom selects. Facebook employs WAI-ARIA to assign meaning to them, so users of more recent assistive technology have no trouble using them. Since the installed base still has many users of older technology that does not support WAI-ARIA, however, we cannot recommend this approach at the time being (compare our article The Accessibility of WAI-ARIA on 'A List Apart').

Custom elements also cause problems on user agents (or under customised settings) when  the page is displayed without CSS or with other stylesheets. In this case, users will just see a heap of unstructured, disconnected, unusable elements.


The resulting low test score of 76.75 points hardly differs from the result of the first test looking at the Facebook-registration process. This is not surprising since pages tested now and then have much in common: problems with text scalability (in IE), very weak focus visibility, and bad structuring through headlines and other semantic markup were already apparent there. As in the case of the registration process, there are no insurmountable barriers in using the profile pages, especially as users can access all functions also in the mobile version. What is novel in this test is the rather unncecessary eclectic and inconsistient approach in structuring the forms - something that will be annoying especially for screenreader users.

In the third and final test next month, we will look at the accessibility of the facebook functions used on a daily basis (finding freinds, networking).

Internet adress:

Date of testing: 30. 6. 2011
Test result: 76,75 of 100 Points (badly accessible)

Detailed test report (in German)